Re: Strange "ldd" behaviour on shared libs
On Sat, 20 Sep 1997, Yann Dirson wrote:
> $ ldd libss.so.2.0
> libc.so.5 => /lib/libc.so.5 (0x40007000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x400c3000)
> $ cd ..
> $ ldd ss/libss.so.2.0
> libc.so.6 => /lib/libc.so.6 (0x40007000)
> --list => --list (0x00000000)
> libcom_err.so.2 => /lib/libcom_err.so.2 (0x400a5000)
> libc.so.5 => /lib/libc.so.5 (0x400a7000)
> =====
>
> After reading ldd.1, I wonder whether it does mean anything (nothing
> told about shared libs deps; don't even know whether it's implemented
> somewhere).
>
> Anyway, the 1st run really seems relevant. The reference to libc5 may
> come from the fact that ldd looks at a libc5 libcom_err in /lib, but
> then why doesn't it show in the 1st case ?
If you do "ldd name" without any path, ldd looks first in the usual
directories (/lib:/usr/lib:...) So, the first time it found the libss.so.2.0
in /libm but the second time it found the right one.
This may bite you also when you run dpkg-shlibdeps. If you want to
find the dependencies for a library in the current directory, you
must run "dpkg-shlibdeps ./libfoo.so.m.n"
^^
--
Enrique Zanardi ezanardi@noah.dfis.ull.es
Dpto. Fisica Fundamental y Experimental
Univ. de La Laguna
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: