i emerged gcc-3.3.2-r5 because it has become stable. after that, emerge wouldn't start because it couldn't find linstdc++.so.5 after some panic i found out that i just had to run ldconfig because the cache was not up-to-date: root # ldconfig -p|grep libstdc libstdc++.so.5 (libc6) => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5 libstdc++.so.5 (libc6) => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5 libstdc++.so.2.9 (libc6) => /usr/lib/libstdc++.so.2.9 libstdc++.so.2.8 (libc6) => /usr/lib/libstdc++.so.2.8 libstdc++.so.2.7.2 (libc6) => /usr/lib/libstdc++.so.2.7.2 libstdc++.so (libc6) => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so libstdc++.so (libc6) => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so libstdc++-libc6.2-2.so.3 (libc6) => /usr/lib/libstdc++-libc6.2-2.so.3 libstdc++-libc6.1-1.so.2 (libc6) => /usr/lib/libstdc++-libc6.1-1.so.2 so this should be fixed perhaps, although i don't know why that happened. after running ldconfig my system worked again since the entry pointing to gcc-3.2's libstdc++ disappeared. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I think this is a known problem to the developers. It only happened for few persons in the past so it has never been fixed. But this time there seem to be more a lot mor people affected.
/etc/ld.so.conf also still includes the old gcc-3.2 paths. anyway, the portage should run ldconfig after unmerging packages - that should fix it.
portage _should_ call ldconfig after unmerge. /usr/lib/portage/bin/emerge line 1854 from portage-2.0.50 > portage.env_update() should take care of running ldconfig after unmerging if any LDPATH from /etc/env.d has been updated or newly created. /etc/ld.so.conf still contains the old gcc 3.2.3 paths because /etc/env.d/05gcc sets LDPATH to "/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" So env-update will add the gcc 3.2.3 path to /etc/ld.so.conf
but "emerge gcc && ldconfig" works, no problems afterwards since gcc 3.2's libstdc++ is deleted. so if emerge would call ldconfig after an autoclean (i don't know if it's equivalent to an unmerge) than nobody would run in to troubles. look at my the output of my "ldconfig -p". it was just after i emerged gcc 3.3 and it contains 2 entries for libstdc++
I think I have the reason why this happens. After merging gcc-3.3.2 portage.env_update() is called, so that /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2 is added to /etc/ld.so.conf and ldconfig updates /etc/ld.so.cache with libs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2 but because /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3 is still in LDPATH in /etc/env.d/05gcc libs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3 are still included in /etc/ld.so.cache When gcc-3.2.3 has been unmerged portage.env_update() is called another time. But libs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3 will be still included in /etc/ld.so.cache because portage.env_update() will not run ldconfig because LDPATH has not been changed (it still includes both directories). And removed directory /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3 will not lead to run ldconfig. It is skiped, because /usr/lib/portage/pym/portage.py checks only for existing directories at line 702: if os.path.isdir(x): In my opinion /usr/lib/portage/pym/portage.py has to be updated to run ldconfig, if a directory which is recorded in LDPATH and mtimedb has been removed from the filesystem. I'm currently testing this. Stay tuned.
well, ldconfig must also be run if new so-files are added or so-files are deleted. to run ldconfig only when LDPATH has changed is not enough. so portage should check 3 conditions: - new so-files (in case of merge) - delted so-files (in case of unmerge) - LD path changed if any of these 3 conditions are met, ldconfig should be run.
It does run when new libs are added. portage checks the mtime of every directory in LDPATH and if it changed since last run, ldconfig will be run. - new so-files (in case of merge) <-- done via mtime of directories - LD path changed <-- done via checking old path in /etc/ld.so.conf and new generated one - delted so-files (in case of unmerge) <-- partly done via mtime of directories (fails if complete directory mentioned in LDPATH is removed and LDPATH hs not been changed)
So i guess unmerging gcc triggers the last case: the directory is deleted, and portage thinks it's not necessary to run ldconfig.
Created attachment 25204 [details, diff] portage-2.0.50-ldconfig.patch This patch modifies portage.py to run ldconfig if a directory mentioned in LDPATH has been removed from the filesystem but it is still in LDPATH
Instead of running ldconfig, there is another way to fix this. Edit /etc/env.d/05gcc after emerging the updated gcc program. The last line, LDPATH="...", will have both the new and old directories. Remove the old directory, save the file, and run "env-update".
env-update will then run ldconfig for you because LDPATH has changed. So at least it is still ldconfig which fixes the failure. ;) And if you've edited /etc/env.d/05gcc please edit the corresponding file in /etc/env.d/gcc so that a call to gcc-config doesn't overwrite your /etc/env.d/05gcc with the old values. Just to be consistent. ;)
@Dimitriy: We know that there is a way to fix it manually, but emerging gcc 3.3 makes the python unusable. So how should i be abled to run "env-update" if python cannot be executed because libstdc++ cannot be found by ld? @Sven: good patch, i hope portage gets patched.
I fixed this bug on bug 40694 in cvs. *** This bug has been marked as a duplicate of 40694 ***
