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
