On Fri, Dec 13, 2013 at 10:39:57AM -0800, Steve Ellcey wrote: > > 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?
This is not documented anywhere, but when I implemented rpath search in musl's dynamic linker, I made it walk the whole chain of DT_NEEDED references that caused the library to be loaded, starting with the immediate reference. I believe glibc is doing something similar, and this is probably what uclibc should do. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
