1 |
On 12/19/13 12:47 AM, Kent Fredric wrote: |
2 |
> On 19 December 2013 06:33, Jan Kundrát <jkt@g.o> wrote: |
3 |
>> I'm worried by the cost of such a policy, though, because we would suddenly |
4 |
>> have to patch some unknown amount of software |
5 |
> |
6 |
> Given the nature that changing that CXX Flag globally for all users |
7 |
> could cause many packages to spontaneously fail to build, wouldn't |
8 |
> that imply that changing that flag would essentially be de-stabilizing |
9 |
> the whole tree, and a package being (arch) would no longer be an |
10 |
> indication of sane, tested behaviour? |
11 |
> |
12 |
> This is really the perk of the USE driven process, the granular |
13 |
> piecemeal approach that does only as much as necessary, without |
14 |
> changing things that are already stable. |
15 |
In practice wouldn't that mean you'd have to add c++11 USE flag to every |
16 |
C++11 application and lib? |
17 |
|
18 |
I just sent an email with some crazy thoughts - Your point is totally |
19 |
correct - this "migration" needs to happen while not breaking the whole |
20 |
tree. Logistically - what's the best way to maintain both those "ABI" at |
21 |
the same time? |
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 |
Worst case only 1 builds |
29 |
this breaks down into generally 2 cases |
30 |
1. Programs/libs which have intentionally adopted c++11 and don't |
31 |
care about C++03 (clang/llvm/lldb) |
32 |
2. Programs/libs which can't be compiles with c++11 mode |
33 |
|
34 |
|
35 |
/usr/lib64/libfoo.so |