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

[Michał Górny]

Dnia 2013-12-19, o godz. 15:28:46
"C. Bergström" <cbergstrom@×××××××××.com> napisał(a):

> On 12/19/13 03:20 PM, Michał Górny wrote:
> > Dnia 2013-12-19, o godz. 00:56:31
> > "C. Bergström" <cbergstrom@×××××××××.com> napisał(a):
> >
> >> On 12/19/13 12:47 AM, Kent Fredric wrote:
> >>> On 19 December 2013 06:33, Jan Kundrát <jkt@g.o> wrote:
> >>>> I'm worried by the cost of such a policy, though, because we would suddenly
> >>>> have to patch some unknown amount of software
> >>> Given the nature that changing that CXX Flag globally for all users
> >>> could cause many packages to spontaneously fail to build, wouldn't
> >>> that imply that changing that flag would essentially be de-stabilizing
> >>> the whole tree, and a package being (arch) would no longer be an
> >>> indication of sane, tested behaviour?
> >>>
> >>> This is really the perk of the USE driven process, the granular
> >>> piecemeal approach that does only as much as necessary, without
> >>> changing things that are already stable.
> >> In practice wouldn't that mean you'd have to add c++11 USE flag to every
> >> C++11 application and lib?
> > No. Only the libs that change their ABI in C++11.
> >
> >> "Best case" both build and you end up with a linker problem (can be
> >> worked around with compiler patches)
> >> /usr/lib64/libboost.so
> >> /usr/lib64-c++11/libboost.so
> > What's wrong with this solution:
> >
> > 1. distro-specific compiler patching is wrong,
> Pragmatically, this needs to be upstream and should have been there
> already. Get some feedback to see if gcc people are receptive to the
> idea before testing a gentoo-only patch. If they accept it upstream -
> backport it. If they tell you f* off - get their feedback on how to deal
> with it - more below.
>
> (this is not a gentoo only problem - this discussion should happen on a
> more global level...)

And how is this an issue to the major distributions? Binary distros can
do a simple switch with standard all-package upgrade and forget about
it. Like they usually do. Only people who built from sources have to
think about it.

> > 2. kinda FHS deviation, at least in spirit of lib<qual> directory.
> >
> > We could go with '-L' but this is very fragile anyway. It's *very easy*
> > for the compiler to link the 'wrong' library due to -L/usr/lib64 being
> > added by some kind of foo-config.
> -L would likely mean you also need -nostdlib to make it work - which is
> more hacky than the above. pretty please don't do this.. pleeeeaassse

What? I have no idea what you're trying to accomplish but this seems
out of the scope of the problem.

-- 
Best regards,
Michał Górny