| 1 |
On 05/13/2016 06:09 PM, Grant Edwards wrote: |
| 2 |
> On 2016-05-11, Jonathan Callen <jcallen@g.o> wrote: |
| 3 |
> |
| 4 |
>> Looking further at the ebuilds in question, it appears that if you wish |
| 5 |
>> to have older versions of GCC installed with >=gcc-4.9, you need to have |
| 6 |
>> USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't |
| 7 |
>> appear to be completely broken like the old USE=multislot was; now the |
| 8 |
>> SLOTs are constant with respect to USE). |
| 9 |
> |
| 10 |
> So slots no longer "just work" like they have for the past 15 years? |
| 11 |
> |
| 12 |
> You now have to explicitly request installation in a slot by setting |
| 13 |
> the multislot flag? |
| 14 |
> |
| 15 |
> Did I miss an eselect news warning about this? |
| 16 |
> |
| 17 |
> Is this true for all packages that were previously installed in slots, |
| 18 |
> or have gcc and a select few been chosen specially for this breakage? |
| 19 |
> |
| 20 |
|
| 21 |
In this case, it's *just* GCC that has this issue. It appears that the |
| 22 |
definition of the "multislot" flag for sys-devel/gcc, |
| 23 |
sys-devel/gcc-apple, and sys-devel/kgcc64 changed from meaning "Make all |
| 24 |
the SLOTs include the minor version" (so SLOT=4.9.3) to "Allow multiple |
| 25 |
versions of GCC to be installed at all (instead of one per CTARGET)" |
| 26 |
[although it doesn't quite do that yet; reason unknown]. This change |
| 27 |
appears to have been committed back in March, the reason we are all |
| 28 |
seeing it hit now (as of 8 May) is that portage finally has a reason to |
| 29 |
want to recompile GCC, because there is a new "vtv" flag available (for |
| 30 |
vtable verification). |
| 31 |
|
| 32 |
-- |
| 33 |
Jonathan Callen |
Archives