Andrea Chiavelli posted <[EMAIL PROTECTED]>, excerpted below, on Tue, 10 Jan 2006 19:08:51 +0100:
> I've recently installed gentoo for amd64 2005.1-r1. After the first > emerge sync and emerge -u portage I had this bad surprise: after > upgrading gcc from 3.4.3 (I thing this was the previous version > installed) to 3.4.4 emerge exited with the error: "/usr/bin/python: > error while loading shared libraries: libstdc++.so.6: cannot open shared > object file: No such file or directory". And so was the output of > env-update and other key-programs. > Actually on my system there isn't libstdc++.so.6 (except from a copy in > /emul/linux/x86/usr/lib/ which is useless i'm afraid). And so I think > that this is not a simple problem of environment variables. However I've > corrected the /etc/ld.so.conf, run ldconfig and gcc-config and even > fix_libtool_files.sh but no way! that library is really missing! And > also the old gcc installation has gone! > Please have ideas? I'm really astonished! Ouch! To prevent getting in such binds in the future, I'd suggest adding buildpkg to your FEATURES line in make.conf. This will cause portage to build and archive binary packages (binpkgs) for everything it merges, so rollback to previous versions, or simply checking what files a package contained and retrieving specific files if necessary, is /much/ easier. The binpkgs are then stored by default in /usr/portage/packages. This will require about a gig of space to store a complete system, 2-4 gigs for comfort, depending on how often you want to clean out old and stale packages. (Mine is currently 1.2 gigs, with multiple versions of some packages stored.) The binpkg format is simply a tar.bz2 with some extra portage metadata tacked onto the end, so even when portage won't run, as long as you can access a working tar and bzip2, even from a rescue disk if necessary, you can extract what you need out of the tarballs to get back to a working system. Meanwhile, checking my gcc binpkgs, both gcc-3.4.3 and 3.4.4 have libstdc++ shared objects, located in /usr/lib/gcc/x86_64-pc-linux-gnu/<gccver>/. Both have a libstdc++.so.6 symlink, pointed at libstdc++.so.6.0.3, in the same directory. Thus, you /should/ have a symlink /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6, which points to libstdc++.so.6.0.3, which should exist in the same dir. If you /do/ have both files, you should be able to get back a working system by simply creating a symlink in the old location, probably the 3.4.3 dir where 3.4.4 is above (tho my 3.4.3 is actually dated, so 3.4.3-20050110 is the dir here), pointed at the new libstdc++.so.6.0.3 or whatever, in the new location. If you do /not/ have the files in the new location, /then/ you have a rather different and more serious problem. Are you sure you didn't merge the new GCC with USE=nocxx? That would of course produce a C-only, no C++, version of gcc, which would of course not have a libstdc++. Obviously, that's not such a good idea on most systems, as it breaks portage, but it's there for systems that don't have their own portage. Of course, it could also be some other problem that resulted in no libstdc++ shared-object at all, or one broken in some way. Anyway, if the files don't exist to be symlinked to, you'll need to find a binpkg of gcc and at minimum, extract the library out of it, before you can tackle the question of why you didn't get the file in the first place. Or, if you still have the stage tarball or liveCD you installed from, you should be able to find an appropriate libstdc++.so.6.whatever file on it, and copy it over, instead of finding a gcc binpkg to use. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list
