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@g.o mailing list