| View previous topic :: View next topic |
| Author |
Message |
Xenophon
n00b
Joined: 08 Jun 2003
Posts: 20
Location: London, UK
|
 Posted: Fri Jun 27, 2003 5:31 am Post subject: Error loading shared libraries post gcc upgrade, glibc build |
 |
|
First of all, let me apologize for all of the I-have-read-this-before comments. I have seen several posts regarding a similar problem, but none of the remedies posted therein worked, and I have decided to document this attempt more thoroughly, so I can avoid rehashing those threads.
I am having problems after upgrading gcc and recompiling glibc and binutils. Specifically, I get "error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory" whenever attempting to run anything linked against it (for example, python- the basic gentoo tool).
Note: I have read the installation guide and the gcc upgrade guide. Please do not refer me back to those documents unless you notice an error I have made in following them.
I started with a blank slate and a stage 1 tarball. I mounted my directories, untarred the first stage, copied resolv.conf and mounted proc, and chrooted to /mnt/gentoo. env-update and source /etc/profile. I have done this many times, never had problems before, and had none now.
I then proceeded to emerge sync and edit make.conf. My flags are as follows:
| Code: | CFLAGS="-mcpu=pentium4 -march=pentium3 -O3 -pipe -mfpmath=sse -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}" |
Note: I have read the CFLAGS threads. Since I have a Pentium 4, but gcc 3.2.2 cannot properly emit code with -march=pentium4, I set my flags to something safe that has worked multiple times before. As far as I can tell, anything sensitive to the optimization flags (i.e., glibc) strips them out where necessary.
I then moved on to stage two:
| Code: | cd /usr/portage
scripts/bootstrap.sh |
Everything worked. No problems so far. I then moved on to stage three:
Everything worked. No problems so far. I then tested my compiler and linker by creating a hello.cpp file:
| Code: | #include <iostream>
int main () { std::cout << "Hello world." << std::endl; }
|
Compiling it with
| Code: | | g++ hello.cpp -o hello |
gave me an executable file that printed the desired text. I wanted to check the libraries used, and so running ldd on it gave me libstdc++.so.5 and libgcc_s.so.1, among others.
I then proceeded to upgrade gcc according to the guide. First, I went into /usr/portage/sys-devel/gcc/gcc-3.2.3-r1.ebuild and changed the KEYWORDS line by replacing "~x86 ..." with "x86".
Note: I know that gcc-3.2.3 is masked for 'instability'. On the other hand, stable.gentoo.org reports 6/6 satisfied customers, and the bugfixes are worth it for a Pentium 4 system user such as myself.
After 'manually' selecting gcc-3.2.3 by temporarily marking it stable, I upgraded gcc:
This updated gcc-config, selected gcc-3.2.3-r1, built it, and installed it without any (visible) problems. I then updated my profile, according to the upgrade guide:
| Code: | rm /etc/make.profile
ln -s /usr/portage/profiles/default-x86-1.4 /etc/make.profile |
I then realized that nothing had happened because I had used a 1.4 tarball. No harm done. I then proceeded update my environment with 'source /etc/profile' and list my gcc profiles with 'gcc-config --list-profiles', which gave me:
| Code: | | [1] i686-pc-linux-gnu-3.2.3 |
That looked right, and 'gcc-config i686-pc-linux-gnu-3.2.3' changed nothing, so I assumed it had successfully upgraded. I ran the 'hello world' test mentioned above, and it succeeded. 'ldd hello' confirmed that it had, in fact, linked against the same libraries, but this time in '/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3'- which I believe was correct.
Then I continued to
| Code: | | emerge glibc binutils |
which succeeded.
Then the 'hello world' program compiled and linked, but failed to execute. I cursed. The error went like this:
| Code: | | ./hello: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory |
I cursed again, and realized my system was cat foo bar. In fact, just running 'python' gave me:
| Code: | | python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory |
This meant I couldn't run env-update, or emerge, or anything essential to normal gentoo functioning.
I wanted to see what libraries my 'hello' program linked against, to document the error. 'ldd hello' returned:
| Code: | libstdc++.so.5 => not found
libm.so.6 => /lib/libm.so.6 (0x40016000)
libgcc_s.so.1 => not found
libc.so.6 => /lib/libc.so.6 (0x40038000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) |
So libstdc++ and libgcc_s.so.1 were missing. I cursed some more. I needed to know where they were, so I ran 'ldconfig -v', which told me everything I needed to know:
| Code: | /lib:
/usr/lib:
/usr/local/lib:
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3:
|
which meant it found no libraries whatsoever. I continued cursing. Then I checked the appropriate locations for my libraries.
'ls /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3' returned:
| Code: | cc1 jc1 libgcj.a libstdc++.a
cc1obj jvgenmain libgcj.la libstdc++.la
cc1plus libfrtbegin.a libgcj.so libstdc++.so
collect2 libg2c.a libgcj.so.3 libstdc++.so.5
cpp0 libg2c.la libgcj.so.3.0.0 libstdc++.so.5.0.3
crtbegin.o libg2c.so libgcj.spec libsupc++.a
crtbeginS.o libg2c.so.0 libiberty.a libsupc++.la
crtbeginT.o libg2c.so.0.0.0 libobjc.a security
crtend.o libgcc.a libobjc.la specs
crtendS.o libgcc_eh.a libobjc.so tradcpp0
f771 libgcc_s.so libobjc.so.1
include libgcc_s.so.1 libobjc.so.1.0.0 |
so the libraries were in there, and
'ls -l /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++*' returned
| Code: | -rw-r--r-- 1 root root 4152062 Jun 27 03:59 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.a
-rwxr-xr-x 1 root root 917 Jun 27 03:59 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.la
lrwxrwxrwx 1 root root 18 Jun 27 03:59 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so -> libstdc++.so.5.0.3
lrwxrwxrwx 1 root root 18 Jun 27 03:59 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5 -> libstdc++.so.5.0.3
-rwxr-xr-x 1 root root 1072068 Jun 27 03:59 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5.0.3 |
which meant the symlinks were all right. But 'ldconfig -p' reported
| Code: | | 0 libs found in cache `/etc/ld.so.cache' |
So why couldn't ldconfig see the libraries?
I looked at /etc/ld.so.conf:
| Code: | # ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/local/lib
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3 |
So ldconfig should have noticed the libraries. I cursed at ldconfig. I checked the contents of /etc/env.d, and everything looked fine. More particularly,
| Code: | | diff /etc/env.d/gcc/i686-pc-linux-gnu-3.2.3 /etc/env.d/05gcc |
returned no difference in the two files. Not that it would make a difference, since I couldn't run env-update, but I wanted to make sure.
To summarize:
gcc-3.2.3 is built from gcc-3.2.3-r1.ebuild and works;
glibc and binutils were emerged sucessfully;
ldconfig is configured correctly, and the c++ library paths are in ld.so.conf, but ldconfig cannot see the libraries;
this means that python (and thus emerge and env-update and countless other useful tools) are borked; and
I have run out of good curses.
Any suggestions? I will edit this (tremendously long) post for typos and accidental omissions as people notice them.
Last edited by Xenophon on Fri Jun 27, 2003 7:06 pm; edited 1 time in total |
|
| Back to top |
|
 |
Xenophon
n00b
Joined: 08 Jun 2003
Posts: 20
Location: London, UK
|
| Posted: Fri Jun 27, 2003 2:07 pm Post subject: |
|
|
27 reads and no suggestions. I'm going to report this as a bug, since I can't find any duplicates. I'll update the bug as I hear from others.
Edit: The bug has been reported as #23599 on bugs.gentoo.org. |
|
| Back to top |
|
|
Xenophon
n00b
Joined: 08 Jun 2003
Posts: 20
Location: London, UK
|
| Posted: Mon Jun 30, 2003 3:53 pm Post subject: Bug Bloggery |
|
|
To anyone watching this thread, if you have the same problem, you can also discuss it at the bug report.
Also, I think the problem might actually be related to the binutils emerge. Not only does `ldconfig' not find the libraries, but even after symlinking all my libraries to /lib, `ldconfig -p' finds 0 libraries at all. |
|
| Back to top |
|
|
Xenophon
n00b
Joined: 08 Jun 2003
Posts: 20
Location: London, UK
|
| Posted: Tue Jul 08, 2003 7:33 am Post subject: Solved, I think. |
|
|
The solution to the problem is simple. While upgrading to gcc 3.2.3, glibc and a number of other packages are upgraded. An emerge -e world silently reverts those packages (the relevant problem being the glibc downgrade). I use the adjective "silently" because emerge -ep world simply indicates all packages as new, and does not indicate that any packages are being downgraded. The only solution I have found is to rebuild world with gcc 3.2.2 and the earlier glibc.
A workaround to get gcc 3.2.3 working might be to
| Code: | | ARCH_KEYWORDS="~x86" emerge -ep gcc |
and then find each ebuild listed and convert it from unstable "~x86" to stable "x86" and stick it in the PORDIR_OVERLAY directory so that emerge sync will let them be. Then
| Code: | emerge -e gcc
emerge -e world |
should work. |
|
| Back to top |
|
|
21582
n00b
Joined: 31 May 2003
Posts: 20
|
| Posted: Tue Jul 08, 2003 6:40 pm Post subject: |
|
|
Same problem, different solution (take a look at https://forums.gentoo.org/viewtopic.php?t=65809):
I marked glibc-2.3.2 as stable by removing the tilde in front of "x86" in the ebuild "glibc-2.3.2-r1.ebuild".
I remerged this version of glibc, rebooted and everything worked again (ldconfig finding the libraries).
Though surely not necessary, I continued with "emerge -e world" to recompile all packages, including kdebase, and as far as I can say now, my system is both stable and useable. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
