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

getting dpkg-shlibdeps to work on the Hurd



Hi,

(Please keep me and Jeff CC'ed.  Group reply is your friend :)

there is an unresolved issue with dpkg-shlibdeps on the Hurd.  I ignored
this in the past, because it was thought that this would be resolved
automatically by using objdump rather than ldd, but then ldd was
reintroduced and so we need to take a more active stance ;)

The issue is that the Hurd has /usr linked to ., so that all libraries that
are usually found in /usr/lib are found in /lib, and likewise all libraries
usually found in /usr/X11R6/lib are found in /X11R6/lib.  Because /lib is
always searched first (in fact, on the Hurd it is the only place searched by
the system, if none of the other possibilities of the ELF standard are used,
like rpath or LD_LIBRARY_PATH).  Note that we are following the ELF standard
just about verbatim (I have not checked, but I don't know of any deviation).

In particular, ldd outputs the libraries with the shorter path, which puts
/lib first, and does not show the /usr/ paths at all.  Those paths are then
used to invoke dpkg, which of course fails to find the libraries.  The
result is a lack of dependencies.

objdump shows only the soname of the libs, and not the path, so it doesn't
share this problem.  This comes at the cost that we don't know which library
is used if several are possible.  It's not usual to have two libraries with
the same soname installed, as only one can be used anyway, but there was one
important case this happened: In the libc5 transition.  So ldd was
reintroduced into dpkg-shlibdeps to find out if we are talking libc5 or
libc6 here, and it works fine for GNU/Linux (which has a funky intelligent
but non-standard linker who can figure this out).

I am happy to do all the work in writing a patch and testing it to fix the
situation for the Hurd, but I would like to know what your preferred
solution is.  Currently, I am using a hack that just searches all three
standard places in Debian for the libraries.  By far the best way to get
this resolved is to simply not use the ldd stuff at all on the Hurd, but
only use objdump and let dpkg figure out which dependencies are relevant.
We will never allow two different libraries with the same soname on the
Hurd systems and let the linker figure out which one to use.  So this would
work fine for us.  Also, your preference on things like run-time check of
the system or check at build time would be nice to know, as this is highly
subjective, and I would like to work out a patch that gives you least trouble.

Of course, if you prefer to work this in directly, without going the long
way around, even better.  I am happy to test whatever you come up with.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


-- 
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: