View previous topic :: View next topic |
Author |
Message |
jeffk l33t
Joined: 13 Sep 2003 Posts: 671
|
Posted: Thu Feb 05, 2004 2:10 pm Post subject: glib emerge b0rked libstdc++.so.5 symlink, how to repair? |
|
|
Being new to gentoo and still in the 'doing things with portage that you shouldn't do' stage, I foolishly 'emerge system''d with ACCEPT_KEYWORDS="x86 ~x86". It bailed during the emerge of either glibc or zlib, probably the former. Although most other things still work, my laptop now has a broken portage:
Code: | /usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: no such file or directory. |
The pretend seemed reasonable, the only thing that looked dire was glibc, and I figured that upgrading the glibc now before I got everything else up and running was preferable. If you're going to break things, do it early The version bump was pretty minor.
I think the issue boils down to a missing symlink that would put libstdc++.so.5.0.5 on the path through a redirection. The target directory with its symlinks looks normal.
Code: | # ls -l /usr/lib/gcc-lib/i686-pc-linux-gnu-3.3.2/libstdc++*
libstdc++.a
libstdc++.la
libstdc++.so -> libstdc++.so.5.0.5
libstdc++.so.5 -> libstdc++.so.5.0.5
libstdc++.so.5.0.5 |
Is there anything I can look into to see where the system should be symlinking to these targets? I can emerge anything until I get this fixed. Thanks. |
|
Back to top |
|
|
jeffk l33t
Joined: 13 Sep 2003 Posts: 671
|
Posted: Thu Feb 05, 2004 2:19 pm Post subject: Re: glib emerge b0rked libstdc++.so.5 symlink, how to repair |
|
|
jeffk wrote: | Being new to gentoo and still in the 'doing things with portage that you shouldn't do' stage, I foolishly 'emerge system''d with ACCEPT_KEYWORDS="x86 ~x86". It bailed during the emerge of either glibc or zlib, probably the former. Although most other things still work, my laptop now has a broken portage: |
I should mention that the machine had been running and emerging fine for a few days, this was not the emerge system that follows bootstrapping. I got myself into trouble because I can't get X working with the nvidia module yet, leaving me with too much console-only time and not enough web-browser to read up.
Idle mice are the devil's work |
|
Back to top |
|
|
CAVi n00b
Joined: 03 Feb 2004 Posts: 3
|
Posted: Thu Feb 05, 2004 7:56 pm Post subject: |
|
|
do an ldconfig |
|
Back to top |
|
|
jeffk l33t
Joined: 13 Sep 2003 Posts: 671
|
Posted: Thu Feb 05, 2004 7:59 pm Post subject: |
|
|
CAVi wrote: | do an ldconfig |
Holy (Barry The) Cow! That did it. Never knew ldconfig did *that*. Thank you very much CAVi. I'm very grateful! |
|
Back to top |
|
|
jeffk l33t
Joined: 13 Sep 2003 Posts: 671
|
Posted: Thu Feb 05, 2004 8:13 pm Post subject: |
|
|
Last question (related to this anyway). When I was messing around with that manual symlinking of a few of the versions, I made a boneheaded mistake:
rm /usr/lib/stdc++*
Yep, they ought to take away my linux permit. Only move dumber than that was once typing "# ifconfig eth0 down" when working on a remote machine over ssh.
That command took out:
/usr/lib/libstdc++.so.2.2.7.2.8
/usr/lib/libstdc++-2-libc6.1-1-2.9.0
/usr/lib/libstdc++-3-libc6.2-2-2.10.0
/usr/lib/libstdc++-libc6.2-2.so.3
/usr/lib/libstdc++.so.2.8
/usr/lib/libstdc++.so.2.9
/usr/lib/libstdc++.so.2.7.2
/usr/lib/libstdc++.so.2.8.0
/usr/lib/libstdc++.so.2.9.0
/usr/lib/libstdc++-libc6.1-1.so.2
Which I can get from another machine, but not of the same mcpu type.
What can I do (now that emerge is working again) to a) check what those files were owned by, and b) what emerge to run to put them back. I'm doing glibc now, we'll see what that does. |
|
Back to top |
|
|
|