On Fri, Feb 23, 2001 at 12:32:44AM +0100, Robert Bihlmeyer wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > The issue is that it now uses ldd again to find out not only the name but > > also the location of the libraries used by the binary. Because ldd finds > > them all under /lib in the Hurd, dpkg-shlibdeps won't be able to find them > > via dpkg -S, when they are installed under /usr/lib. > > Actually, objdump is still used to produce the list of immediate > dependencies [ldd will also list indirect dependencies]. As this list > does not include paths, "ldconfig -p" output is used to find them. > This will fail on the Hurd.
Thanks for the exact information. > > 1. Don't use ldd on the Hurd at all. It's not needed. Just using objdump as > > it was done in a short period before ldd was used again worked fine. The > > reason to use ldd on linux doesn't apply for us (it was a libc5 > > compatibility thing). > > ... should probably be: Don't use ldconfig on the Hurd - assume that > all libraries reside under /lib. > > Should this work? In any case, it's not very clean. Well, not all libraries are in /lib, for example X libs aren't. When we use runpath, more libs might not be in standard places, but then we will have the path inthe binary, so it will be easy. > The whole issue is symptom of the assumption that the dpkg file > database will hold the one and only location of a particular file. [...] Wichert says he rewrites dpkg-shlibdeps with this in mind, let's see what comes out of it. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
