[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: