dynamic linker / rpath question

[Rich Felker]

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