I just installed a new amd64 instance, and chose the no-multilib profile. I updated world, and chose to add a few toolchain components to package.keywords (gcc-4.5, glibc-2.13). The update went fine, and the system works nicely. However, after trying to select the new gcc, I spotted a nice error message: * source /etc/profile * Switching native-compiler to x86_64-pc-linux-gnu-4.5.2 ...>>> Regenerating /etc/ld.so.cache... [ ok ] * Running 'fix_libtool_files.sh 4.4.5' * fix_libtool_files.sh: /lib/rcscripts/awk/fixlafiles.awk does not exist! This seemed a little strange, so I checked, and sure enough: thinkpad ~ $ ls -dl /lib/ drwxr-xr-x 2 root root 4096 May 8 13:16 /lib/ The only thing showing up in /lib is 'cpp' . While there is probably a small bug in gcc-config expecting the symlink to be present, according to the variables, the symlink should have never disappeared in the first place: thinkpad ~ $ portageq envvar -v SYMLINK_LIB LIBDIR_x86 LIBDIR_amd64 SYMLINK_LIB='yes' LIBDIR_x86='lib32' LIBDIR_amd64='lib64' So, I'm not sure exactly where the bug lies - perhaps in the no-multilib profile? Reproducible: Always
Sorry, I just spotted an error - the missing /lib/rcscripts/awk/fixlafiles.awk actually came about when I was removing the old gcc (4.4.5), not during the initial switch with gcc-config.
(In reply to comment #0) > thinkpad ~ $ ls -dl /lib/ > drwxr-xr-x 2 root root 4096 May 8 13:16 /lib/ ls(1) is highly unreliable. :) wieneke ~ # ls -ld /lib/ /lib lrwxrwxrwx 1 root root 5 May 11 06:56 /lib -> lib64 drwxr-xr-x 10 root root 4096 May 12 19:30 /lib/ Note that it lists the output in a specific order instead of in the order of the command line arguments, which is of minor importance. However, the output of `ls -d' varies depending on whether you add the trailing slash.
1) Please post your `emerge --info' output too. 2) Tell us which stage tarball you used.
(In reply to comment #2) > (In reply to comment #0) > > thinkpad ~ $ ls -dl /lib/ > > drwxr-xr-x 2 root root 4096 May 8 13:16 /lib/ > > ls(1) is highly unreliable. :) > > wieneke ~ # ls -ld /lib/ /lib > lrwxrwxrwx 1 root root 5 May 11 06:56 /lib -> lib64 > drwxr-xr-x 10 root root 4096 May 12 19:30 /lib/ > > Note that it lists the output in a specific order instead of in the order of > the command line arguments, which is of minor importance. However, the output > of `ls -d' varies depending on whether you add the trailing slash. Ah, sorry; I am pretty positive the symlink was gone, regardless of my poor coreutils skills :) I noticed after /lib/ seems basically empty. Regarding the profile, stage tarball, it was actually fine upon extraction, and the symlink only disappeared after a world update (I suspect rebuilding glibc) with the no-multilib profile.
(In reply to comment #3) > 2) Tell us which stage tarball you used. Please? The thing has a creation date, possibly you even have the URL.
(In reply to comment #5) > (In reply to comment #3) > > 2) Tell us which stage tarball you used. > > Please? The thing has a creation date, possibly you even have the URL. Ah, sorry; sure, I posted the bug immediately (and did the update to world right after install, too), so I would say: "stage3-amd64-20110428.tar.bz2" just to be clear, the symlink was there after the stage extraction, and only disappeared after selecting the no-multilib profile, and updating world (again, I have a feeling glibc).
What is your glibc version?
(In reply to comment #3) > 1) Please post your `emerge --info' output too. Ah yes...
The behavior seems similar to http://bugs.gentoo.org/show_bug.cgi?id=358143
Similar, but I think that stage3 has 2.11.3 already. I know this because I used the same tarball just days ago to set up a no-multilib system myself (yay, finally I have amd64!) and didn't see this issue. Not that this information helps, I'm just thumping my chest here.
(In reply to comment #10) > Similar, but I think that stage3 has 2.11.3 already. I know this because I used > the same tarball just days ago to set up a no-multilib system myself (yay, > finally I have amd64!) and didn't see this issue. Not that this information > helps, I'm just thumping my chest here. Well, yes but the problem was in the multilib eclass not in the glibc ebuild. But if you say that the the latest amd64 tarballs + no-multilib worked for you then it may not be related to the old bug.
Sorry, I won't have access for an emerge --info for a few days (I'm not sure which specific piece of information will be useful, by the way?) I also knew that the multilib profile had the problem awhile ago, which is what led me to believe that perhaps it was also broken in the no-multilib profile (but with fewer consumers, may have not been as noticed). For glibc versions, I updated to 2.13-r2, but, as mentioned above, believe the issue is more related to the profile than the ebuild.
I tried twice over the weekend to reproduce this, using the same make.conf, stage3 tarball, and no-multilib profile, but could not. So, I think I will close as invalid for now - sorry for the noise (and lack of explanation!). Thanks for the help!
