dynamic linker / rpath question

[Steve Ellcey]

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
sellcey at mips.com