[uClibc] ld.so loading "false" libs

[Peter S. Mazinger]

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?
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)?
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?

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.
glibc's ldconfig show /lib:/usr/lib (hardcoded) + what is in ld.so.conf in 
order (no duplication)

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2


____________________________________________________________________
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol.
Probald ki most! http://www.freestart.hu