Jeremy Huddleston <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [email protected] mailing list
