1 |
Andrea Chiavelli posted <43C3F833.1080800@×××××××.it>, excerpted below, |
2 |
on Tue, 10 Jan 2006 19:08:51 +0100: |
3 |
|
4 |
> I've recently installed gentoo for amd64 2005.1-r1. After the first |
5 |
> emerge sync and emerge -u portage I had this bad surprise: after |
6 |
> upgrading gcc from 3.4.3 (I thing this was the previous version |
7 |
> installed) to 3.4.4 emerge exited with the error: "/usr/bin/python: |
8 |
> error while loading shared libraries: libstdc++.so.6: cannot open shared |
9 |
> object file: No such file or directory". And so was the output of |
10 |
> env-update and other key-programs. |
11 |
> Actually on my system there isn't libstdc++.so.6 (except from a copy in |
12 |
> /emul/linux/x86/usr/lib/ which is useless i'm afraid). And so I think |
13 |
> that this is not a simple problem of environment variables. However I've |
14 |
> corrected the /etc/ld.so.conf, run ldconfig and gcc-config and even |
15 |
> fix_libtool_files.sh but no way! that library is really missing! And |
16 |
> also the old gcc installation has gone! |
17 |
> Please have ideas? I'm really astonished! |
18 |
|
19 |
Ouch! |
20 |
|
21 |
To prevent getting in such binds in the future, I'd suggest adding |
22 |
buildpkg to your FEATURES line in make.conf. This will cause portage to |
23 |
build and archive binary packages (binpkgs) for everything it merges, so |
24 |
rollback to previous versions, or simply checking what files a package |
25 |
contained and retrieving specific files if necessary, is /much/ easier. |
26 |
The binpkgs are then stored by default in /usr/portage/packages. This |
27 |
will require about a gig of space to store a complete system, 2-4 gigs |
28 |
for comfort, depending on how often you want to clean out old and stale |
29 |
packages. (Mine is currently 1.2 gigs, with multiple versions of some |
30 |
packages stored.) The binpkg format is simply a tar.bz2 with some extra |
31 |
portage metadata tacked onto the end, so even when portage won't run, as |
32 |
long as you can access a working tar and bzip2, even from a rescue disk if |
33 |
necessary, you can extract what you need out of the tarballs to get back |
34 |
to a working system. |
35 |
|
36 |
Meanwhile, checking my gcc binpkgs, both gcc-3.4.3 and 3.4.4 have |
37 |
libstdc++ shared objects, located in |
38 |
/usr/lib/gcc/x86_64-pc-linux-gnu/<gccver>/. Both have a libstdc++.so.6 |
39 |
symlink, pointed at libstdc++.so.6.0.3, in the same directory. |
40 |
|
41 |
Thus, you /should/ have a symlink |
42 |
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6, which points to |
43 |
libstdc++.so.6.0.3, which should exist in the same dir. |
44 |
|
45 |
If you /do/ have both files, you should be able to get back a working |
46 |
system by simply creating a symlink in the old location, probably the |
47 |
3.4.3 dir where 3.4.4 is above (tho my 3.4.3 is actually dated, so |
48 |
3.4.3-20050110 is the dir here), pointed at the new libstdc++.so.6.0.3 or |
49 |
whatever, in the new location. |
50 |
|
51 |
If you do /not/ have the files in the new location, /then/ you have a |
52 |
rather different and more serious problem. Are you sure you didn't merge |
53 |
the new GCC with USE=nocxx? That would of course produce a C-only, no |
54 |
C++, version of gcc, which would of course not have a libstdc++. |
55 |
Obviously, that's not such a good idea on most systems, as it breaks |
56 |
portage, but it's there for systems that don't have their own portage. Of |
57 |
course, it could also be some other problem that resulted in no libstdc++ |
58 |
shared-object at all, or one broken in some way. |
59 |
|
60 |
Anyway, if the files don't exist to be symlinked to, you'll need to find a |
61 |
binpkg of gcc and at minimum, extract the library out of it, before you |
62 |
can tackle the question of why you didn't get the file in the first place. |
63 |
Or, if you still have the stage tarball or liveCD you installed from, you |
64 |
should be able to find an appropriate libstdc++.so.6.whatever file on it, |
65 |
and copy it over, instead of finding a gcc binpkg to use. |
66 |
|
67 |
-- |
68 |
Duncan - List replies preferred. No HTML msgs. |
69 |
"Every nonfree program has a lord, a master -- |
70 |
and if you use the program, he is your master." Richard Stallman in |
71 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
72 |
|
73 |
|
74 |
-- |
75 |
gentoo-amd64@g.o mailing list |