[gentoo-amd64] eselect-compiler multilib updates

[gentoo-amd64] eselect-compiler multilib updates

[Jeremy Huddleston]

Sorry I've been a bit inactive of late, but I had a few cycles last  
week, so I fixed up the eselect-compiler ebuild to better handle the  
transition from gcc-config and updated toolchain.eclass to update all  
toolchains for the profile (ie it'll update both the x86_64 and i686  
compiler when a new version of gcc is emerged).  I'd like to remove  
it from package.mask sometime soon, but I'd like to make sure these  
changes fix up all those kinks.  I've tested it out a bit on my amd64  
and x86 profiles, but I'd like to get more feedback.  So if anyone  
still using gcc-config wouldn't mind testing it out, it'd be  
appreciated.  All you need to do is add the following to /etc/portage/ 
package.unmask:

app-admin/eselect-conmpiler

then emerge eselect-compiler and unmerge gcc-config.  If you need  
backwards compatibility, you can also add the following to  
package.unmask:
sys-devel/gcc-config

then just update gcc-config instead of unmerging it.  This just gives  
you a wrapper which takes the same syntax as the older gcc-configs  
and makes the appropriate call to eselect-compiler.

Please report any bugs you find in bugzilla and assign them directly  
to me (eradicator@gentoo.org).  After I'm sure this is working good  
for us on amd64, I'll ask for more preople on gentoo-dev to test it  
out before finally unmasking it.

Thanks,
Jeremy

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] eselect-compiler multilib updates

[Vladimir G. Ivanovic]

OK, I emerged eselect-compiler and all's well so far.

When I went to unemerge gcc-config, I got a scary ;-) message: 

        !!! 'sys-devel/gcc-config' is part of your system profile.
        !!! Unmerging it may be damaging to your system.

Before I unemerge gcc-config can I back out eselect-compiler and restore
the old gcc-config if things go awry?

--- Vladimir

P.S. I changed the native CTARGET from i686-pc-linux-gnu to
x86_64-pc-linux-gnu. I assume this is the right thing to do since my
machine is an AMD64. I do not seem to have CTARGET set anywhere, in
particular, it's not in my /etc/make.conf.


On Tue, 2006-05-30 at 12:43 -0700, Jeremy Huddleston wrote:
> Sorry I've been a bit inactive of late, but I had a few cycles last  
> week, so I fixed up the eselect-compiler ebuild to better handle the  
> transition from gcc-config and updated toolchain.eclass to update all  
> toolchains for the profile (ie it'll update both the x86_64 and i686  
> compiler when a new version of gcc is emerged).  I'd like to remove  
> it from package.mask sometime soon, but I'd like to make sure these  
> changes fix up all those kinks.  I've tested it out a bit on my amd64  
> and x86 profiles, but I'd like to get more feedback.  So if anyone  
> still using gcc-config wouldn't mind testing it out, it'd be  
> appreciated.  All you need to do is add the following to /etc/portage/ 
> package.unmask:
> 
> app-admin/eselect-conmpiler
> 
> then emerge eselect-compiler and unmerge gcc-config.  If you need  
> backwards compatibility, you can also add the following to  
> package.unmask:
> sys-devel/gcc-config
> 
> then just update gcc-config instead of unmerging it.  This just gives  
> you a wrapper which takes the same syntax as the older gcc-configs  
> and makes the appropriate call to eselect-compiler.
> 
> Please report any bugs you find in bugzilla and assign them directly  
> to me (eradicator@gentoo.org).  After I'm sure this is working good  
> for us on amd64, I'll ask for more preople on gentoo-dev to test it  
> out before finally unmasking it.
> 
> Thanks,
> Jeremy
> 

Vladimir G. Ivanovic
Palo Alto, CA 94306
+1 650 678 8014
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: eselect-compiler multilib updates

[Duncan]

Jeremy Huddleston <eradicator@gentoo.org> posted
1E2EC852-245D-4E9A-ADC5-9C8F08ECEF92@gentoo.org, excerpted below, on  Tue,
30 May 2006 12:43:34 -0700:

> I had a few cycles last  
> week, so I fixed up the eselect-compiler ebuild to better handle the  
> transition from gcc-config and updated toolchain.eclass to update all  
> toolchains for the profile (ie it'll update both the x86_64 and i686  
> compiler when a new version of gcc is emerged).  I'd like to remove  
> it from package.mask sometime soon, but I'd like to make sure these  
> changes fix up all those kinks.

I've been running the masked one for some time (as you know given the bugs
I filed on it =8^).  As such, I haven't tested an upgrade from the old
gcc-config, but...

After upgrading first eselect-compiler, to 2.0.0_rc1-r2, then gcc to
4.1.1, both on May 26...

$eselect compiler list
Available compilers for CTARGET i686-pc-linux-gnu
  [1]   x86_64-pc-linux-gnu-3.4.6/x86-hardened
  [2]   x86_64-pc-linux-gnu-3.4.6/x86-hardenednopie
  [3]   x86_64-pc-linux-gnu-3.4.6/x86-hardenednopiessp
  [4]   x86_64-pc-linux-gnu-3.4.6/x86-hardenednossp
  [5]   x86_64-pc-linux-gnu-3.4.6/x86-vanilla
  [6]   x86_64-pc-linux-gnu-4.0.3/x86-vanilla
  [7]   x86_64-pc-linux-gnu-4.1.0/x86-vanilla
  [8]   x86_64-pc-linux-gnu-4.1.1/x86-vanilla
Available compilers for CTARGET x86_64-pc-linux-gnu
  [9]   x86_64-pc-linux-gnu-3.4.6/amd64-hardened
  [10]  x86_64-pc-linux-gnu-3.4.6/amd64-hardenednopie
  [11]  x86_64-pc-linux-gnu-3.4.6/amd64-hardenednopiessp
  [12]  x86_64-pc-linux-gnu-3.4.6/amd64-hardenednossp
  [13]  x86_64-pc-linux-gnu-3.4.6/amd64-vanilla
  [14]  x86_64-pc-linux-gnu-4.0.3/amd64-vanilla
  [15]  x86_64-pc-linux-gnu-4.1.0/amd64-vanilla
  [16]  x86_64-pc-linux-gnu-4.1.1/amd64-vanilla

Activated profiles:
  i686-pc-linux-gnu         x86_64-pc-linux-gnu-4.1.0/x86-vanilla
  x86_64-pc-linux-gnu *     x86_64-pc-linux-gnu-4.1.1/amd64-vanilla

$ls -1 /etc/eselect/compiler/
selection.conf
x86_64-pc-linux-gnu-3.4.6.conf
x86_64-pc-linux-gnu-4.0.3.conf
x86_64-pc-linux-gnu-4.1.0.conf
x86_64-pc-linux-gnu-4.1.1.conf

I have USE=-multislot for gcc, so 4.1.1 replaced 4.1.0. 
As you can see from the above output, eselect-compiler updated the x86_64
entry to point to the new gcc, but failed to update the i686 entry, which
still points at the now invalid 4.1.0. Further, the stale and
invalid 4.1.0 entries were not removed and remain available for attempted
selection.  Looks like I still have to update the i686 entry manually, and
remove stale /etc/eselect/compiler/* entries manually as well.

Of course, that isn't a problem with eselect-compiler itself, but rather,
it would seem, with the various eselect-compiler functions in
toolchain.eclass.  I just took a brief look and toolchain.eclass does have
eselect-compiler functions and logic, presumably your work, but it appears
a bit more work may be necessary before unmasking, unless you tweaked
further after my emerges on May 26.

If you need more testing and want a bit faster responses, mail me directly
if you wish.  Be sure it's plain text so it doesn't get caught in my spam
filter, but yeah, I'm up for trying eclass patches or the like, and
recompiling gcc a few times to try things out, if necessary.  Handling
removal of stale config files manually isn't a big problem here, and I've
been managing it for some time, but it's something that should be fixed
before unmasking, I'm sure you'll agree.

Very cool idea, BTW, handling both archs, and obviously a step up from
current gcc-config, or I wouldn't have bothered with the manual updates
this past year.  The core, the part that's working, works very well, and 
I've been quite happily using it, occasional manual updates and the former
manual initial setup, or not. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] eselect-compiler multilib updates

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

On Tue, 30 May 2006 12:43:34 -0700
Jeremy Huddleston <eradicator@gentoo.org> wrote:

> then emerge eselect-compiler and unmerge gcc-config.  If you need  
> backwards compatibility, you can also add the following to  
> package.unmask:
> sys-devel/gcc-config

The following depend on sys-devel/gcc-config (only); of particular note
are sys-libs/glibc, syslibs/libstdc++ and syslibs/libffi:


sys-devel/distcc 2.18.3-r10 2.16-r2 2.18.3-r6 2.18.3-r8 2.16-r3
2.18.3-r7

sys-devel/gcc-powerpc64 3.4.4

sys-devel/gcc-sparc64 3.3.6 3.4.6 3.3.5 3.4.5

sys-devel/gcc-hppa64 3.3.2 3.4.5 3.3.2-r1

sys-devel/gcc-mips64 3.4.5 3.4.4

media-gfx/sam2p 0.44

sys-process/supervise-scripts 3.5

sys-apps/ucspi-proxy 0.95

sys-libs/glibc 2.3.5-r2 2.3.5 2.3.6-r1 2.4-r1 2.3.6-r3 2.3.5-r1 2.4-r3 
2.3.4.20041102-r2 2.3.5-r3 2.3.6 2.3.6-r2 2.4-r2 2.3.4.20050125-r1
2.3.6-r4

sys-libs/libstdc++-v3 3.3.3-r1 3.3.4 3.3.6

net-mail/qtools 0.56

net-mail/relay-ctrl 3.1.1-r2

dev-lang/ccc 6.5.9.001-r1 6.5.9.001-r3 6.5.9.001 6.5.6.002 6.5.9.001-r2

dev-lang/cxx 6.5.9.31-r1 6.5.9.31

dev-lang/cfal 1.2.0.4

dev-libs/libffi 3.4.1-r1 3.4.1 3.3.5 3.4.3


So unmerging gcc-config will cause portage to try to pull it back in on
"emerge -puDv world" etc.  Many of them use gcc-config to get info
about the compiler (they should probably be using toolchain-funcs, I
think). I don't really see why several of these depend on gcc-config
(e.g. glibc!), but maybe I'm missing something.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-amd64] eselect-compiler multilib updates

[Jeremy Huddleston]

On May 31, 2006, at 00:52 , Vladimir G. Ivanovic wrote:

> OK, I emerged eselect-compiler and all's well so far.
>
> When I went to unemerge gcc-config, I got a scary ;-) message:
>
>         !!! 'sys-devel/gcc-config' is part of your system profile.
>         !!! Unmerging it may be damaging to your system.

Uh... yeah just ignore that.  I also put gcc-config in package.mask  
just to make sure it doesn't get pulled in on accident.

> Before I unemerge gcc-config can I back out eselect-compiler and  
> restore
> the old gcc-config if things go awry?

Definitely.  All you need to do is emerge gcc-config and umnerte  
eselect-compiler, then source /etc/profile.

> --- Vladimir
>
> P.S. I changed the native CTARGET from i686-pc-linux-gnu to
> x86_64-pc-linux-gnu. I assume this is the right thing to do since my
> machine is an AMD64. I do not seem to have CTARGET set anywhere, in
> particular, it's not in my /etc/make.conf.

Was the default set to i686-*?  If so, that's definitely a bug, and I  
think I know where the problem is, so I'll go fix it.  Thanks.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] eselect-compiler multilib updates

[Jeremy Huddleston]

I actually fixed the glibc DEPENDS around the time I sent the email,  
and I didn't realize there were so many other packages that directly  
depend on it.  glibc depends on it for crosscompiler support (that's  
just from the comment in the ebuild made by vapier.  I actually don't  
understand why myself, but crossdev is his baby.)

In that case, I definitely recommend unmasking sys-devel/gcc-config  
as well (via /etc/portage/package.unask) so the compatibility wrapper  
will be installed, too.

I'll work at getting all those other packages fixed to use toolchain- 
funcs.eclass or use eselect-compiler directly, but if anyone wants to  
jump in, be my guest.

--Jeremy

On May 31, 2006, at 06:57 , Kevin F. Quinn wrote:

> On Tue, 30 May 2006 12:43:34 -0700
> Jeremy Huddleston <eradicator@gentoo.org> wrote:
>
>> then emerge eselect-compiler and unmerge gcc-config.  If you need
>> backwards compatibility, you can also add the following to
>> package.unmask:
>> sys-devel/gcc-config
>
> The following depend on sys-devel/gcc-config (only); of particular  
> note
> are sys-libs/glibc, syslibs/libstdc++ and syslibs/libffi:
>
>
> sys-devel/distcc 2.18.3-r10 2.16-r2 2.18.3-r6 2.18.3-r8 2.16-r3
> 2.18.3-r7
>
> sys-devel/gcc-powerpc64 3.4.4
>
> sys-devel/gcc-sparc64 3.3.6 3.4.6 3.3.5 3.4.5
>
> sys-devel/gcc-hppa64 3.3.2 3.4.5 3.3.2-r1
>
> sys-devel/gcc-mips64 3.4.5 3.4.4
>
> media-gfx/sam2p 0.44
>
> sys-process/supervise-scripts 3.5
>
> sys-apps/ucspi-proxy 0.95
>
> sys-libs/glibc 2.3.5-r2 2.3.5 2.3.6-r1 2.4-r1 2.3.6-r3 2.3.5-r1 2.4-r3
> 2.3.4.20041102-r2 2.3.5-r3 2.3.6 2.3.6-r2 2.4-r2 2.3.4.20050125-r1
> 2.3.6-r4
>
> sys-libs/libstdc++-v3 3.3.3-r1 3.3.4 3.3.6
>
> net-mail/qtools 0.56
>
> net-mail/relay-ctrl 3.1.1-r2
>
> dev-lang/ccc 6.5.9.001-r1 6.5.9.001-r3 6.5.9.001 6.5.6.002  
> 6.5.9.001-r2
>
> dev-lang/cxx 6.5.9.31-r1 6.5.9.31
>
> dev-lang/cfal 1.2.0.4
>
> dev-libs/libffi 3.4.1-r1 3.4.1 3.3.5 3.4.3
>
>
> So unmerging gcc-config will cause portage to try to pull it back  
> in on
> "emerge -puDv world" etc.  Many of them use gcc-config to get info
> about the compiler (they should probably be using toolchain-funcs, I
> think). I don't really see why several of these depend on gcc-config
> (e.g. glibc!), but maybe I'm missing something.
>
> -- 
> Kevin F. Quinn

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: eselect-compiler multilib updates

[Jeremy Huddleston]

> $ls -1 /etc/eselect/compiler/
> selection.conf
> x86_64-pc-linux-gnu-3.4.6.conf
> x86_64-pc-linux-gnu-4.0.3.conf
> x86_64-pc-linux-gnu-4.1.0.conf
> x86_64-pc-linux-gnu-4.1.1.conf
>
> I have USE=-multislot for gcc, so 4.1.1 replaced 4.1.0.
> As you can see from the above output, eselect-compiler updated the  
> x86_64
> entry to point to the new gcc, but failed to update the i686 entry,  
> which
> still points at the now invalid 4.1.0. Further, the stale and
> invalid 4.1.0 entries were not removed and remain available for  
> attempted
> selection.  Looks like I still have to update the i686 entry  
> manually, and
> remove stale /etc/eselect/compiler/* entries manually as well.
>

The old profiles are there because the files are in /etc which means  
they're not removed when the version of gcc is unmerged.  This is  
fixed if you emerge the newest eselect-compiler, but you'll still  
need to remove the old profile files manually.  I should add  
something to the ebuild to remove invalid profiles after the first  
install since the CONFIG_PROJECT_MASK won't be valid until AFTER  
eselect-compiler is installed.  Thanks for pointing this out.


> Of course, that isn't a problem with eselect-compiler itself, but  
> rather,
> it would seem, with the various eselect-compiler functions in
> toolchain.eclass.  I just took a brief look and toolchain.eclass  
> does have
> eselect-compiler functions and logic, presumably your work, but it  
> appears
> a bit more work may be necessary before unmasking, unless you tweaked
> further after my emerges on May 26.
>

That depends on when on the 26th.  I committed my changes on the  
26th, so I'm not sure what you have.  My fixes actually specifically  
target updating _both_ the i686 and x86_64 compiler.  I actually  
tested this by using the 4.1.1_pre* gcc, then emerging 4.1.1.  I saw  
both the i686 and x86_64 compiler get updated.  Perhaps you missed  
the fix by a few hours.  The toolchain.eclass commit was made a few  
hours after eselect-compiler was updated.


> If you need more testing and want a bit faster responses, mail me  
> directly
> if you wish.  Be sure it's plain text so it doesn't get caught in  
> my spam
> filter, but yeah, I'm up for trying eclass patches or the like, and
> recompiling gcc a few times to try things out, if necessary.  Handling
> removal of stale config files manually isn't a big problem here,  
> and I've
> been managing it for some time, but it's something that should be  
> fixed
> before unmasking, I'm sure you'll agree.
>

Yes, I definitely agree here.  The problem is with portage not  
unmerging the files with gcc and QA wanting the base profile not to  
include the override for eselect-compiler.  This forced me to set  
CONFIG_PROJECT_MASK via env.d for users who have eselect-compiler,  
but that strands profiles for users who unmerge gcc before they get  
eselect-compiler... thus I'm going to need to cleanup /etc/eselect/ 
compiler on the first merge.


>
> Very cool idea, BTW, handling both archs, and obviously a step up from
> current gcc-config, or I wouldn't have bothered with the manual  
> updates
> this past year.  The core, the part that's working, works very  
> well, and
> I've been quite happily using it, occasional manual updates and the  
> former
> manual initial setup, or not. =8^)
>

Great.  Glad to see it working well for you.  I've been using it as  
well, and I'm just glad I got it to a usable state before work tore  
me away from the project for so long.  Hopefully I can get this  
finished soon and start working on something similar for binutils.

--Jeremy

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: eselect-compiler multilib updates

[Duncan]

Jeremy Huddleston <eradicator@gentoo.org> posted
E404CD4D-C436-43C8-AC25-F9EE90355851@gentoo.org, excerpted below, on  Thu,
01 Jun 2006 01:48:16 -0700:

> The old profiles are there because the files are in /etc which means  
> they're not removed when the version of gcc is unmerged.

Duh.  I was tired when I wrote about that and it shows, as the fact that
CONFIG_PROTECT was involved never occurred to me!  Lucky that
factoid wasn't a cobra or I'd be in a morgue by now!  Oh, well, still
needed addressed, so it's for the best anyway. =8^)

> This is fixed if you emerge the newest eselect-compiler, but you'll still
> need to remove the old profile files manually.  I should add something
> to the ebuild to remove invalid profiles after the first install since
> the CONFIG_PROJECT_MASK won't be valid until AFTER eselect-compiler is
> installed.  Thanks for pointing this out.

Just merged -rc1-r4.  I removed the 4.1.0 entry manually, and will do a
bit more testing later today or early AM (right now another cobra might
bite me! =8^).

>> Of course, [the problem is] toolchain.eclass[,] unless you tweaked
>> further after my emerges on May 26.
>>
> That depends on when on the 26th.  I committed my changes on the 26th,
> so I'm not sure what you have.[] I actually tested this by
> using the 4.1.1_pre* gcc, then emerging 4.1.1.  I saw both the i686 and
> x86_64 compiler get updated.  Perhaps you missed the fix by a few hours.
>  The toolchain.eclass commit was made a few hours after eselect-compiler
> was updated.

I probably missed it then.  I'll be testing it later...
 
>> but it's something that should be fixed
>> before unmasking, I'm sure you'll agree.
>>
> Yes, I definitely agree here.  The problem is with portage not unmerging
> the files with gcc and QA wanting the base profile not to include the
> override for eselect-compiler.  This forced me to set
> CONFIG_PROJECT_MASK via env.d for users who have eselect-compiler, but
> that strands profiles for users who unmerge gcc before they get
> eselect-compiler... thus I'm going to need to cleanup /etc/eselect/
> compiler on the first merge.

Um... which came first, the chicken or the egg?  <g> I guess that's about
what you are stuck with.  Certainly a challenge!

>> Very cool idea, BTW
>>
> Great.  Glad to see it working well for you.  I've been using it as
> well, and I'm just glad I got it to a usable state before work tore me
> away from the project for so long.  Hopefully I can get this finished
> soon and start working on something similar for binutils.

I'll be watching to see how it turns out.  Actually having to manually
write that first config based on your pattern, then see how it changed
with each upgrade...  Let's just say that being there at that stage of the
process lends itself to learning opportunities one would almost certainly
otherwise miss, if one jumped in after it's all automated.  Sure, it's a
bit of a hassle from time to time handling the stuff manually, but the
drilling does reinforce the lesson.  I'll be looking forward to the same
sort of learning opportunities with binutils.  I love that sort of
hands-on learning, including the risk and challenge it entails, while at
the same time exploring the leading edge before most people have any idea...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] eselect-compiler multilib updates

[Vladimir G. Ivanovic]

On Thu, 2006-06-01 at 01:31 -0700, Jeremy Huddleston wrote:

> > P.S. I changed the native CTARGET from i686-pc-linux-gnu to
> > x86_64-pc-linux-gnu. I assume this is the right thing to do since my
> > machine is an AMD64. I do not seem to have CTARGET set anywhere, in
> > particular, it's not in my /etc/make.conf.
> 
> Was the default set to i686-*?  If so, that's definitely a bug, and I  
> think I know where the problem is, so I'll go fix it.  Thanks.

Yes, the default was set to i686-*.

Thanks for your other comments. I'll nuke gcc-config.

--- Vladimir

Vladimir G. Ivanovic
Palo Alto, CA 94306
+1 650 678 8014
-- 
gentoo-amd64@gentoo.org mailing list