I think the summary pretty much describes the problem. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. Actual Results: libstdc++.so.5 exists nowhere, so groff and python (and thus emerge), and anything else built against it is broken. Had to workaround by manually rebuilding python against libstdc++.so.6 and re-merging the rest. Expected Results: If gcc-3.3.5-r1 is the last version of gcc that has libstdc++.so.5, it should have extra logic upon its unmerging: the ebuild should refuse to unmerge on the grounds that all the programs built to link against libstdc++.so.5 still do so, and print a diagnostic telling the user which programs these are so the user may remerge them to link to the new version of libstdc++. At that point, a depclean should suffice to get rid of the old gcc.
Ouch! Why is libstdc++-v3 missing in PDEPEND then?
same for libstdc++.so.6 upgrading to 3.4.4 on ~x86
The actual problem is, that some time ago python got removed nocxx from ebuild thus depending on the installed c++ library. This dependency is no good for recovery and the user has no chance to recover due to the fact that emerge is nuked. My proposal is generally to keep emerge system at least nocxx where possible (it is no problem w/ db/ncurses, where only separate libs are created for cxx, not like python)
(In reply to comment #2) > same for libstdc++.so.6 upgrading to 3.4.4 on ~x86 Not possible. Your problem sound more like Bug 94959.
Hi, Absolutely brand new system today. Built it this afternoon from 2005.0. After getting the system up and running, I created my user account, I did an emerge sync and then kicked off an emerge --update --deep --newuse system. Now it seems to be completely dead: localhost root # emerge -pv system /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory localhost root # emerge sync /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory localhost root # emerge info /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory localhost root # Is there any known fix for this? I don't mind starting over but I bet I'll hit the same problem again without some guidance on what emerge really caused this. Thanks all.
OK, I edited my /etc/ld.so.conf file to look like this: localhost root # cat /etc/ld.so.conf # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /usr/local/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130 localhost root # Then I ran ldconfig and after that and env-update and things seem to be working. I don't know whether that last line was supposed to be added and wasn't, or whether I should take it out later. Anyway, this seems to work for me.
(In reply to comment #6) > OK, I edited my /etc/ld.so.conf file to look like this: > Then I ran ldconfig and after that and env-update and things seem to be working. Guys, are you really MISSING libstdc++.so.5, or is it just out of path in /etc/ld.so.conf? The latter problem is dupe of Bug 94959.
Jakub, I thought that was clear from my response at 2005-06-04 19:28 PDT. The file existed but it's path was not in ld.so.conf. However more than that was required to get running again. I also had to figure out about gcc-config stuff. I'm not a programmer or system administrator so it's incorrect in my case to think that all Gentoo users know about this stuff. I read a couple of posts about this sort of problem last evening on Gentoo-user and pieced together enough info to get my machine limping again but now I have hand edited files that I've never touched before so I'm concerned that it will break again. Also I'm not doing updates on 5 Gentoo machines for our family until I get some confidence again in portage. This really bothered me. I do not understand how htis can happen on stable machine. I thought this gets worked out on ~x86 first?!? - Mark
OK, marking this one as duplicate. *** This bug has been marked as a duplicate of 94959 ***
