Re: [gentoo-dev] How to support C++11 in libraries?

[C. Bergström]

On 12/19/13 12:33 AM, Jan Kundrát wrote:
> On Wednesday, 18 December 2013 18:05:46 CEST, "C. Bergström" wrote:
>> If moving to C++11 - Isn't that considered just part of the work
>> along the path? There's some clang tools to help with the migration,
>> but I don't think anyone expects it to be zero work. The flag is just
>> a way to a) enable building programs that can be built with c++11 b)
>> flush out the culprits in the cases it can't be. If (b) is a bug -
>> how else to find it easily?
>
> This perspective is interesting (and I admit that I tend to like it)
> -- considering packages which won't build with C++11 to be buggy.
>
> I'm worried by the cost of such a policy, though, because we would
> suddenly have to patch some unknown amount of software (and I'm pretty
> sure some upstreams would reject these patches anyway). If we were an
> enterprise distro with binary compatibility requirements, we would
> also have to worry about that and either assume that the ABI changes
> are non-issue in real world, or provide two versions of all C++
> libraries. I tried to check how RHEL7 will deal with it, but I wasn't
> able to find any information about that. It also seems that Fedora
> hasn't addressed this yet, either.
>
> Either way, it is reasonable to assume that some users would like to
> build their own software and link it with system libraries. It is not
> reasonable to force these users to build in the C++11 mode, IMHO.
I want my cake and eat it too!

/* Off the cuff crazy ideas and not meant to be taken too seriously */

In my mind this is almost similar to ABI (incompatibilities) between 32 
and 64bit. Why not just (ab)use the multilib approach for c++11?

/usr/lib64-c11/

It would possibly (likely) require some patching to clang/g++ when the 
--std=c++11 flag is used, but might allow the extension of a c++11 
library universe while leaving the things which are working today 
unbroken. The main problem I see with this is proliferation of more crap 
in /usr/lib* (4 variations instead of just the 2 (32vs64) we have now). 
(Personally, I'd typically build *only* 64bit versions and 32bit x86 can 
go to hell...)

To get support from the "enterprise" distros - I'd try to move the 
discussion of this problem upstream to the LSB level. They will at some 
point need to solve this same problem as well. It's not like it'll be 
gentoo specific forever. (You guys are just pioneering and ahead of the 
curve.. this isn't the same thing as -Omgfast)

With this approach - would it make sense to create a new profile?

I don't know if a USE flag would in general get pushback, but if the 
c++11 use flag was used - it would put those libs in /usr/lib64-c11/