1 |
On Wed, Apr 26, 2017 at 5:32 AM, Andreas K. Huettel |
2 |
<dilfridge@g.o> wrote: |
3 |
> Am Mittwoch, 26. April 2017, 02:37:17 CEST schrieb Francesco Riosa: |
4 |
>> 2017-04-26 0:26 GMT+02:00 Andreas K. Huettel <dilfridge@g.o>: |
5 |
>> > Am Sonntag, 23. April 2017, 14:35:48 CEST schrieb Michał Górny: |
6 |
>> > > Hi, |
7 |
>> > > |
8 |
>> > > I'm thinking of masking old versions of sys-devel/gcc, in particular |
9 |
>> > > older than the 4.9 branch. |
10 |
>> > |
11 |
>> > Masking is fine; some time later (maybe in a few months) I'd even suggest |
12 |
>> > masking all of gcc-4. After all, unmasking them if you really need them is |
13 |
>> > rather easy. |
14 |
>> |
15 |
>> well if the intent is cleaning adding a package mask is just more burden, |
16 |
>> not less. |
17 |
>> If they compile fine with the latest stable gcc better leave them unmasked, |
18 |
>> right? |
19 |
> |
20 |
> Except that "switching back" from gcc-5 to gcc-4 doesn't really work, and that |
21 |
> gcc-4 will happily use gcc-5 libraries, with unintended consequences. |
22 |
|
23 |
What do you mean by "gcc-4 will happily use gcc-5 libraries"? |
24 |
|
25 |
If you mean at build time, it does NOT use gcc-5 libs. If it does, that's a bug. |
26 |
|
27 |
% gcc-4.9.4 --print-search-dirs | grep ^libraries: |
28 |
libraries: =/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.9.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../x86_64-pc-linux-gnu/4.9.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.9.4/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.9.4/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../:/lib/:/usr/lib/ |
29 |
|
30 |
If you mean runtime, that's controlled by |
31 |
/etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf. There's really |
32 |
nothing wrong with using a newer libstdc++ at runtime; they should be |
33 |
ABI compatible. |