[uClibc] ld.so loading "false" libs

[Peter S. Mazinger]

On Sat, 25 Sep 2004, Joakim Tjernlund wrote:

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

my arch is x86, why do I have 0x00000000?
> 
> > 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.

I will try that

> > 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.

Well, it doesn´t

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