On 12/13/2013 7:39 PM, 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
This is very strange. The libstdc++.so doesn't have any RPATH set.
Morover the libgcc_s.so
should be found in the standard search path, then the dynamic linker
doesn't need any info
to find it. Could you build the shared library loader with debugging
support (SUPPORT_LD_DEBUG=y)
to see where the dynamic linker search the libraries.
In any case the dynamic tag RPATH as searching path are handled
differently by the glibc and uclibc
dynamic linker.
In particular the latter consider the executable's RPATH as searching
path to look for immediate
dependencies, while the glibc one the executable's RPATH is used as
searching path for all
dependencies chain.
Looking the ABI documentation the uclibc dynamic linker does the right
think.
http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies
"The set of directories specified by a given |DT_RUNPATH| entry is used
to find only the immediate dependencies of the executable or shared
object containing the |DT_RUNPATH| entry. That is, it is used only for
those dependencies contained in the |DT_NEEDED| entries of the dynamic
structure containing the |DT_RUNPATH| entry, itself. One object's
|DT_RUNPATH| entry does not affect the search for any other object's
dependencies. "
Some time ago I raised a similar issue, see
"Use executable's RPATH in looking up library searching path." thread in
http://lists.uclibc.org/pipermail/uclibc/2011-September/thread.html
Hope this help you.
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]
Regards,
Filippo
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
