[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Jonathan Callen]

On 05/16/2016 12:34 PM, meino.cra...@gmx.de wrote:
> Jonathan Callen  [16-05-16 14:09]:
>> On 05/13/2016 06:09 PM, Grant Edwards wrote:
>>> On 2016-05-11, Jonathan Callen  wrote:
>>>
 Looking further at the ebuilds in question, it appears that if you wish
 to have older versions of GCC installed with >=gcc-4.9, you need to have
 USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't
 appear to be completely broken like the old USE=multislot was; now the
 SLOTs are constant with respect to USE).
>>>
>>> So slots no longer "just work" like they have for the past 15 years?
>>>
>>> You now have to explicitly request installation in a slot by setting
>>> the multislot flag?
>>>
>>> Did I miss an eselect news warning about this?
>>>
>>> Is this true for all packages that were previously installed in slots,
>>> or have gcc and a select few been chosen specially for this breakage?
>>>
>>
>> In this case, it's *just* GCC that has this issue.  It appears that the
>> definition of the "multislot" flag for sys-devel/gcc,
>> sys-devel/gcc-apple, and sys-devel/kgcc64 changed from meaning "Make all
>> the SLOTs include the minor version" (so SLOT=4.9.3) to "Allow multiple
>> versions of GCC to be installed at all (instead of one per CTARGET)"
>> [although it doesn't quite do that yet; reason unknown].  This change
>> appears to have been committed back in March, the reason we are all
>> seeing it hit now (as of 8 May) is that portage finally has a reason to
>> want to recompile GCC, because there is a new "vtv" flag available (for
>> vtable verification).
>>
>> -- 
>> Jonathan Callen
>>
> 
> 
> Hi,
> 
> me again, the problem owner...
> 
> I read elsewhere, that the ANDROID-IDE and crosscompiling
> for Atmel-chips has a problem with newer versions of gcc
> than those being installed on my system before the glitch
> in the Matrix happened.
> 
> I cannot decipher the message of thread exactly enough
> to decide whether that glitch is a problem of emerge/portage
> and need to be fixed there (and I have to wait until then) or
> whether I am able to fix it (I dont like workarounds for 
> tools, which decide over the go/no go of a system which
> is based on gcc that much as Gentoo does, though).
> 
> And...if I have to fix something:
> What exactly should I do?
> 
> Thanks for any help for a non-Neo in advance!
> Best regards,
> Meino
> 

The simplest solution to get multiple versions of GCC installed at the
same time is to add "sys-devel/gcc multislot" to your
/etc/portage/package.use (if using crossdev (and you know if you are),
you also would want "cross-CTARGET/gcc multislot", where CTARGET is the
target of your crossdev install).

This will remove all of the blockers on older versions of GCC, at the
expense of having to recompile some/all of them.  The only thing that
the multislot flags controls at this point is the blockers; not having
USE=multislot prevents old versions from remaining installed (i.e.,
setting the flag *allows* old versions to remain installed).

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Meino . Cramer]

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


Hi,

me again, the problem owner...

I read elsewhere, that the ANDROID-IDE and crosscompiling
for Atmel-chips has a problem with newer versions of gcc
than those being installed on my system before the glitch
in the Matrix happened.

I cannot decipher the message of thread exactly enough
to decide whether that glitch is a problem of emerge/portage
and need to be fixed there (and I have to wait until then) or
whether I am able to fix it (I dont like workarounds for 
tools, which decide over the go/no go of a system which
is based on gcc that much as Gentoo does, though).

And...if I have to fix something:
What exactly should I do?

Thanks for any help for a non-Neo in advance!
Best regards,
Meino

[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Jonathan Callen]

On 05/13/2016 06:09 PM, Grant Edwards wrote:
> On 2016-05-11, Jonathan Callen  wrote:
> 
>> Looking further at the ebuilds in question, it appears that if you wish
>> to have older versions of GCC installed with >=gcc-4.9, you need to have
>> USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't
>> appear to be completely broken like the old USE=multislot was; now the
>> SLOTs are constant with respect to USE).
> 
> So slots no longer "just work" like they have for the past 15 years?
> 
> You now have to explicitly request installation in a slot by setting
> the multislot flag?
> 
> Did I miss an eselect news warning about this?
> 
> Is this true for all packages that were previously installed in slots,
> or have gcc and a select few been chosen specially for this breakage?
> 

In this case, it's *just* GCC that has this issue.  It appears that the
definition of the "multislot" flag for sys-devel/gcc,
sys-devel/gcc-apple, and sys-devel/kgcc64 changed from meaning "Make all
the SLOTs include the minor version" (so SLOT=4.9.3) to "Allow multiple
versions of GCC to be installed at all (instead of one per CTARGET)"
[although it doesn't quite do that yet; reason unknown].  This change
appears to have been committed back in March, the reason we are all
seeing it hit now (as of 8 May) is that portage finally has a reason to
want to recompile GCC, because there is a new "vtv" flag available (for
vtable verification).

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Grant Edwards]

On 2016-05-11, Jonathan Callen  wrote:

> Looking further at the ebuilds in question, it appears that if you wish
> to have older versions of GCC installed with >=gcc-4.9, you need to have
> USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't
> appear to be completely broken like the old USE=multislot was; now the
> SLOTs are constant with respect to USE).

So slots no longer "just work" like they have for the past 15 years?

You now have to explicitly request installation in a slot by setting
the multislot flag?

Did I miss an eselect news warning about this?

Is this true for all packages that were previously installed in slots,
or have gcc and a select few been chosen specially for this breakage?

-- 
Grant Edwards   grant.b.edwardsYow! I feel like I'm
  at   in a Toilet Bowl with a
  gmail.comthumbtack in my forehead!!

Re: [gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Neil Bothwick]

On Wed, 11 May 2016 04:59:32 +0200, Hartmut Figge wrote:

> >I haven't looked into why gcc 4.9 blocks older versions now, although
> >I know it didn't always do so.  
> 
> I was bitten by that problem today. First I masked gcc-4.9 so I was able
> to do an emerge @world.

There's no need to mess with masks, just add "--exclude sys-devel/gcc" to
your emerge command.


-- 
Neil Bothwick

Unix is user-friendly. It's just very selective with who it's friends are.


pgpTr2RboCW4w.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Hartmut Figge]

Jonathan Callen:

>Looking further at the ebuilds in question, it appears that if you wish
>to have older versions of GCC installed with >=gcc-4.9, you need to have
>USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't
>appear to be completely broken like the old USE=multislot was; now the
>SLOTs are constant with respect to USE).

Good guess. :)

Hartmut

[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Jonathan Callen]

On 05/10/2016 10:59 PM, Hartmut Figge wrote:
> Jonathan Callen:
> 
>> I haven't looked into why gcc 4.9 blocks older versions now, although
>> I know it didn't always do so.
> 
> I was bitten by that problem today. First I masked gcc-4.9 so I was able
> to do an emerge @world. Then I commented out the masking of gcc-4.9 and
> tried to emerge it, I got
> 
> i5-64 hafi # emerge -pv  gcc
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R] sys-devel/gcc-4.9.3:4.9.3::gentoo  USE="cxx fortran
> (multilib) nls nptl openmp sanitize vtv%* (-altivec) (-awt) -cilk -debug
> -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot
> -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" 39 KiB
> [blocks B  ]  sys-devel/gcc-4.9.3)
> 
> Total: 1 package (1 reinstall), Size of downloads: 39 KiB
> Conflict: 1 block (1 unsatisfied)
> 
>  * Error: The above package list contains packages which cannot be
>  * installed at the same time on the same system.
> 
>   (sys-devel/gcc-4.9.3:4.9.3/4.9.3::gentoo, ebuild scheduled for merge)
> pulled in by
> gcc
> sys-devel/gcc required by @system
> >=sys-devel/gcc-4.9.3 required by
> (dev-java/icedtea-bin-7.2.6.6-r1:7/7::gentoo, installed)
> 
>   (sys-devel/gcc-4.7.4:4.7.4/4.7.4::gentoo, installed) pulled in by
> sys-devel/gcc:4.7.4 required by @selected
> 
> It seems judicious to stay with the masked gcc until the problem is
> fixed or someone offers a solution.
> 
> Hartmut
> 
> 
> 


Looking further at the ebuilds in question, it appears that if you wish
to have older versions of GCC installed with >=gcc-4.9, you need to have
USE=multislot on the *newer* versions of gcc (this USE=multislot doesn't
appear to be completely broken like the old USE=multislot was; now the
SLOTs are constant with respect to USE).

-- 
Jonathan Callen




signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Hartmut Figge]

Jonathan Callen:

>I haven't looked into why gcc 4.9 blocks older versions now, although
>I know it didn't always do so.

I was bitten by that problem today. First I masked gcc-4.9 so I was able
to do an emerge @world. Then I commented out the masking of gcc-4.9 and
tried to emerge it, I got

i5-64 hafi # emerge -pv  gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R] sys-devel/gcc-4.9.3:4.9.3::gentoo  USE="cxx fortran
(multilib) nls nptl openmp sanitize vtv%* (-altivec) (-awt) -cilk -debug
-doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot
-nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" 39 KiB
[blocks B  ] =sys-devel/gcc-4.9.3 required by
(dev-java/icedtea-bin-7.2.6.6-r1:7/7::gentoo, installed)

  (sys-devel/gcc-4.7.4:4.7.4/4.7.4::gentoo, installed) pulled in by
sys-devel/gcc:4.7.4 required by @selected

It seems judicious to stay with the masked gcc until the problem is
fixed or someone offers a solution.

Hartmut

[gentoo-user] Re: A Glitch in the Matrix or just another burb of emerge... ;)

[Jonathan Callen]

On 05/10/2016 04:03 PM, Alan McKinnon wrote:
> On 10/05/2016 18:14, meino.cra...@gmx.de wrote:
>>
>>
>>   (sys-devel/gcc-4.4.7:4.4/4.4::gentoo, installed) pulled in by
>> sys-devel/gcc:4.4 required by @selected
> 
>>   (cross-armv7a-hardfloat-linux-gnueabi/gcc-4.5.4:4.5/4.5::x-portage, 
>> installed) pulled in by
>> cross-armv7a-hardfloat-linux-gnueabi/gcc:4.5 required by @selected
>
> It's a hard problem to solve, and portage doesn't really know the
> solution. It likely knows how to make itself shut up (remove the low
> version compilers) but that's unlikely to *solve* it. Maybe you really
> want to have 4.4 and 4.9, portage doesn't know how it can give that to
> you so it brain dumps everything it's got and tells you to figure it out.
> 

In this case, you explicitly told portage that you want to keep
sys-devel/gcc:4.4 and cross-armv7a-hardfloat-linux-gnueabi/gcc:4.5
installed, as they are in the @selected set (defined by your world
file).  This means that portage's normal resolution mechanism (remove
the packages that break things) won't work, as that won't satisfy your
requests (as it knows them to be).  I haven't looked into why gcc 4.9
blocks older versions now, although I know it didn't always do so.

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature