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 <[log in to unmask]> 
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).