| 1 |
Jonathan Callen <jcallen@g.o> [16-05-16 14:09]: |
| 2 |
> On 05/13/2016 06:09 PM, Grant Edwards wrote: |
| 3 |
> > On 2016-05-11, Jonathan Callen <jcallen@g.o> wrote: |
| 4 |
> > |
| 5 |
> >> Looking further at the ebuilds in question, it appears that if you wish |
| 6 |
> >> to have older versions of GCC installed with >=gcc-4.9, you need to have |
| 7 |
> >> USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't |
| 8 |
> >> appear to be completely broken like the old USE=multislot was; now the |
| 9 |
> >> SLOTs are constant with respect to USE). |
| 10 |
> > |
| 11 |
> > So slots no longer "just work" like they have for the past 15 years? |
| 12 |
> > |
| 13 |
> > You now have to explicitly request installation in a slot by setting |
| 14 |
> > the multislot flag? |
| 15 |
> > |
| 16 |
> > Did I miss an eselect news warning about this? |
| 17 |
> > |
| 18 |
> > Is this true for all packages that were previously installed in slots, |
| 19 |
> > or have gcc and a select few been chosen specially for this breakage? |
| 20 |
> > |
| 21 |
> |
| 22 |
> In this case, it's *just* GCC that has this issue. It appears that the |
| 23 |
> definition of the "multislot" flag for sys-devel/gcc, |
| 24 |
> sys-devel/gcc-apple, and sys-devel/kgcc64 changed from meaning "Make all |
| 25 |
> the SLOTs include the minor version" (so SLOT=4.9.3) to "Allow multiple |
| 26 |
> versions of GCC to be installed at all (instead of one per CTARGET)" |
| 27 |
> [although it doesn't quite do that yet; reason unknown]. This change |
| 28 |
> appears to have been committed back in March, the reason we are all |
| 29 |
> seeing it hit now (as of 8 May) is that portage finally has a reason to |
| 30 |
> want to recompile GCC, because there is a new "vtv" flag available (for |
| 31 |
> vtable verification). |
| 32 |
> |
| 33 |
> -- |
| 34 |
> Jonathan Callen |
| 35 |
> |
| 36 |
|
| 37 |
|
| 38 |
Hi, |
| 39 |
|
| 40 |
me again, the problem owner... |
| 41 |
|
| 42 |
I read elsewhere, that the ANDROID-IDE and crosscompiling |
| 43 |
for Atmel-chips has a problem with newer versions of gcc |
| 44 |
than those being installed on my system before the glitch |
| 45 |
in the Matrix happened. |
| 46 |
|
| 47 |
I cannot decipher the message of thread exactly enough |
| 48 |
to decide whether that glitch is a problem of emerge/portage |
| 49 |
and need to be fixed there (and I have to wait until then) or |
| 50 |
whether I am able to fix it (I dont like workarounds for |
| 51 |
tools, which decide over the go/no go of a system which |
| 52 |
is based on gcc that much as Gentoo does, though). |
| 53 |
|
| 54 |
And...if I have to fix something: |
| 55 |
What exactly should I do? |
| 56 |
|
| 57 |
Thanks for any help for a non-Neo in advance! |
| 58 |
Best regards, |
| 59 |
Meino |
Archives