1 |
Dnia 2013-12-19, o godz. 00:56:31 |
2 |
"C. Bergström" <cbergstrom@×××××××××.com> napisał(a): |
3 |
|
4 |
> On 12/19/13 12:47 AM, Kent Fredric wrote: |
5 |
> > On 19 December 2013 06:33, Jan Kundrát <jkt@g.o> wrote: |
6 |
> >> I'm worried by the cost of such a policy, though, because we would suddenly |
7 |
> >> have to patch some unknown amount of software |
8 |
> > |
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 |
|
21 |
No. Only the libs that change their ABI in C++11. |
22 |
|
23 |
> "Best case" both build and you end up with a linker problem (can be |
24 |
> worked around with compiler patches) |
25 |
> /usr/lib64/libboost.so |
26 |
> /usr/lib64-c++11/libboost.so |
27 |
|
28 |
What's wrong with this solution: |
29 |
|
30 |
1. distro-specific compiler patching is wrong, |
31 |
|
32 |
2. kinda FHS deviation, at least in spirit of lib<qual> directory. |
33 |
|
34 |
We could go with '-L' but this is very fragile anyway. It's *very easy* |
35 |
for the compiler to link the 'wrong' library due to -L/usr/lib64 being |
36 |
added by some kind of foo-config. |
37 |
|
38 |
-- |
39 |
Best regards, |
40 |
Michał Górny |