| 1 |
On 12/19/13 03:20 PM, Michał Górny wrote: |
| 2 |
> Dnia 2013-12-19, o godz. 00:56:31 |
| 3 |
> "C. Bergström" <cbergstrom@×××××××××.com> napisał(a): |
| 4 |
> |
| 5 |
>> On 12/19/13 12:47 AM, Kent Fredric wrote: |
| 6 |
>>> On 19 December 2013 06:33, Jan Kundrát <jkt@g.o> wrote: |
| 7 |
>>>> I'm worried by the cost of such a policy, though, because we would suddenly |
| 8 |
>>>> have to patch some unknown amount of software |
| 9 |
>>> Given the nature that changing that CXX Flag globally for all users |
| 10 |
>>> could cause many packages to spontaneously fail to build, wouldn't |
| 11 |
>>> that imply that changing that flag would essentially be de-stabilizing |
| 12 |
>>> the whole tree, and a package being (arch) would no longer be an |
| 13 |
>>> indication of sane, tested behaviour? |
| 14 |
>>> |
| 15 |
>>> This is really the perk of the USE driven process, the granular |
| 16 |
>>> piecemeal approach that does only as much as necessary, without |
| 17 |
>>> changing things that are already stable. |
| 18 |
>> In practice wouldn't that mean you'd have to add c++11 USE flag to every |
| 19 |
>> C++11 application and lib? |
| 20 |
> No. Only the libs that change their ABI in C++11. |
| 21 |
> |
| 22 |
>> "Best case" both build and you end up with a linker problem (can be |
| 23 |
>> worked around with compiler patches) |
| 24 |
>> /usr/lib64/libboost.so |
| 25 |
>> /usr/lib64-c++11/libboost.so |
| 26 |
> What's wrong with this solution: |
| 27 |
> |
| 28 |
> 1. distro-specific compiler patching is wrong, |
| 29 |
Pragmatically, this needs to be upstream and should have been there |
| 30 |
already. Get some feedback to see if gcc people are receptive to the |
| 31 |
idea before testing a gentoo-only patch. If they accept it upstream - |
| 32 |
backport it. If they tell you f* off - get their feedback on how to deal |
| 33 |
with it - more below. |
| 34 |
|
| 35 |
(this is not a gentoo only problem - this discussion should happen on a |
| 36 |
more global level...) |
| 37 |
|
| 38 |
Unfortunately, it's going to be really hard to tell what will break ABI |
| 39 |
and what won't. I guess for ABI compatible packages |
| 40 |
/usr/lib64-c++11/libfoobar.so would be a symlink back to |
| 41 |
/usr/lib64/libfoobar.so |
| 42 |
> |
| 43 |
> 2. kinda FHS deviation, at least in spirit of lib<qual> directory. |
| 44 |
> |
| 45 |
> We could go with '-L' but this is very fragile anyway. It's *very easy* |
| 46 |
> for the compiler to link the 'wrong' library due to -L/usr/lib64 being |
| 47 |
> added by some kind of foo-config. |
| 48 |
-L would likely mean you also need -nostdlib to make it work - which is |
| 49 |
more hacky than the above. pretty please don't do this.. pleeeeaassse |
Archives