[uClibc] ld.so loading "false" libs

Peter S. Mazinger ps.m at gmx.net
Sun Sep 26 14:09:39 UTC 2004


On Sun, 26 Sep 2004, Joakim Tjernlund wrote:

> > On Sun, 26 Sep 2004, Joakim Tjernlund wrote:
> > 
> > > > 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?
> > > 
> > > You probably need to compile uClibc with __LDSO_LDD_SUPPORT #defined
> > 
> > I have it defined
> 
> hmm, ldd will fallback on the old behaviour if something goes wrong. Try doing
> a strace on ldd.
> 
> Did reversing the list in dl-elf.c help?

Not yet, I have enabled cache, and the ld.so.conf entries come first, 
after that the standard paths. I do not know how to reverse this order 
(cache going after standard) and I am not sure if ldconfig -v shows the 
same behaviour as ldso's usage.

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



More information about the uClibc mailing list