I have a question about the uclibc dynamic linker vs. the glibc dynamic linker. I have built a GCC cross-toolchain running on an x86 linux system and targeting the MIPS CPU. If I build with the glibc system library and dynamic linker everything works fine. If I build with uclibc instead and compile a C++ program and run it under the qemu simulator I get:
./x: can't load library 'libgcc_s.so.1' In both cases, I use -L and -rpath arguments when linking the executable to let the program know where the shared libraries are. After some digging I found I could 'fix' this problem by using a -rpath argument when building libstdc++ so that it knew where to find libgcc_s.so.1. I do not have to do this for a toolchain using glibc. So I think that when running an executable linked against a shared library (libstdc++.so) that in turn is linked against a second shared library (libgcc_s.so) the uclibc dynamic linker is looking for rpath's in the first shared library (libstdc++.so) to find libgcc_s.so but the glibc dynamic linker is using the rpath's from the executable to find libgcc_s.so Can anyone tell me if I am right about this? Are there options to change the behaviour of the uclibc dynamic linker or options to change the GCC libstdc++ build to deal with this issue? Steve Ellcey [email protected] _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
