[uClibc] ld.so loading "false" libs

[Joakim Tjernlund]

> Hello!
> 
> In a native uclibc env I wanted to build an app, that needs itself to be 
> bootstrapped. This app as binary is only present as glibc version so I 
> have added all the required glibc libs to /usr/X11R6/lib including 
> libc.so.6, ld-linux.so.2 and made a link to /lib/ld-linux.so.2 (I haven't 
> copied any libc.so libm.so files, so at link time it should only find the 
> uclibc versions). I have built alsa-libs and ended up w/ dependency on 
> libc.so.6, although as I said libc.so points to libc.so.0 (uclibc)
> I have also tried to enable ld.so.cache, and put these libs into 
> /usr/X11R6/lib6 adding this path to /etc/ld.so.conf, the same result. 
> 
> Could it be that ld.so (from uClibc) looks for some functions, and if they 
> are found twice, it could get using the false one?

ldso will use the first it finds. The search is done in load order.

> Could this be related to the fact that running ldd it shows all the time 
> (0x00000000) after the used lib (as opposed to glibc's ldd, where there 
> are different values, I think telling us which lib is used (some 
> kind of versioning)?

That is the load address for the lib. On PPC ldd /bin/busubox shows:
        libm.so.0 => /lib/libm.so.0 (0x30016000)
        libcrypt.so.0 => /lib/libcrypt.so.0 (0x3003c000)
        libc.so.0 => /lib/libc.so.0 (0x30060000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x30000000)

> The hardcoded order of libs is /lib:/usr/lib:/usr/X11R6/lib, which has 
> preference? Is this order ok, if a function is found twice, which one is 
> relevant at run-time, the first or the last?

hmm, looking in dl-elf.c, around line 358, it looks like the order used
by uClibc is /usr/X11R6/lib:/usr/lib:/lib. Try reversing that list.
 
> How does the order in ld.so.conf influence this (if ld.so.cache is 
> enabled). if cache is enabled ldconfig show inverse order: first what is 
> in /etc/ld.so.conf, after that the hardcoded /usr/X11R6/lib:/usr/lib:/lib,
> if ld.so.conf includes one of the hardcoded paths, it will be duplicated 
> in ldconfig -v.

Don't know how ld.so.cache works, but I guess it should work like in glibc.

> glibc's ldconfig show /lib:/usr/lib (hardcoded) + what is in ld.so.conf in 
> order (no duplication)