On Thursday 26 June 2014 14:31:22 you wrote: > Hi, > > On Thu, Jun 26, 2014 at 07:42:39AM -0400, Nico Kadel-Garcia wrote: > > On Thu, Jun 26, 2014 at 3:14 AM, ToddAndMargo <toddandma...@zoho.com> wrote: > > > Ye old out-of-date strikes again. Probably will have > > > > > > to wait for SL7. Rats! > > > > > > Thank you for helping me with this, > > > > Or you could "rpm -U file.src.rpm", edit the resulting .spec file to > > manipulate the CFLAGS or other relevant options, and see if that > > builds and runs. I've found in backporting that a lot of complex > > CFLAGS and other build options are optional tuning for performance or > > cross platform compatibility and can be lived without for day to day > > compilation. > > > > But it's hard to tell without actually trying them out. You've got the > > source tarball in the SRPM, perhaps you could run some tests with > > building from that source tarball, or even tweak that .spec file as > > needed? > > Note that bug-free c++11 functionalities were deployed "by successive > iterations" through the last N gcc major releases. Depending on > specifically which c++11 features they used it may or may not work > with any given compiler version (or with gcc4.4). But perhaps it is > worth a try, and you'll be lucky...
Har har... silly me. I forgot, one of the major things dxli had in mind for 2.x was taking advantage of some of the c++11 features that were coming out over the last few years in gcc. Amazing how a major detail like that can slip the mind... seemed like such an obvious thing to do at the time. I think you need the "developer tools" set or whatever its called installed to get a newer gcc to work alongside the older SL6 default one. Someone on this list will surely correct my mis-labeling of whatever that meta package is -- but its the extra packages that include updated runtimes and compilers for RHEL in a way that doesn't obliterate the stock system (pretty darn handy).
