$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
--
[email protected] mailing list
