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

Re: FW: Re: help: shlibs problem



On Sat, 23 Dec 2000, Ben Collins wrote:

> dpkg-shlibdeps does this:

> ldd debian/tmp/bin/foo
>   libc.so.6 => /lib/libc.so.6
>   ld-linux.so.2 => /lib/ld-linux.so.2

> Now, ldd outputs even child deps, so some things in ldd are not actually
> linked to by "foo". So we run objdump to get that list:

> objdump --all debian/tmp/bin/foo | grep NEEDED

>   ld-linux.so.2
>   libc.so.6

> Now you might think that the objdump output is all that's needed, but it
> isn't. Think of something like libX11.so.6 which might be in
> /usr/X11R6/lib/ (for libc6 built) or /usr/i486-linux/lib/ (for libc5
> built). So we "map" the objdump output (the only libs we care about) to
> the ldd output (the systems mapping to the full path), and use that full
> path to the library to ask dpkg what package provides this library.

> So if we cannot get a mapping from ldd, we fail, simply becuase we are
> unsure where this mystery library is coming from (was it linked to from
> /usr/local/foo? /opt/lib? who knows).

However, if objdump lists a library that ldd can't find the path for, and the
library is mentioned in debian/shlibs.local, isn't it reasonable for
dpkg-shlibdeps to assume that this local library is the one it's looking for?
After all, passing LD_LIBRARY_PATH to ldd doesn't help the fact that we
still have to go to debian/shlibs.local to find the binary package name.  Why
not suppress the warning, since it's pretty much meaningless in this case?

Further, the man page says that the debian/shlibs.local file has higher
precedence than shlibs listings for installed packages.  So even if ldd
/does/ find a library with the same soname belonging to an installed package,
it should still use the dependency name from shlibs.local, correct?

Steve Langasek
postmodern programmer



Reply to: