Dnia 2013-12-19, o godz. 15:28:46 "C. Bergström" <cbergst...@pathscale.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" <cbergst...@pathscale.com> napisał(a): > > > >> On 12/19/13 12:47 AM, Kent Fredric wrote: > >>> On 19 December 2013 06:33, Jan Kundrát <j...@gentoo.org> 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
signature.asc
Description: PGP signature
