Bug#317082: Not just a dpkg bug

[Frank Lichtenheld <djpig@debian.org>]

Let's revive this discussion.

On Sun, Aug 21, 2005 at 07:42:54PM +0400, Nikita V. Youshchenko wrote:
> > objdump isn't a solution either, while it sometimes can read the other
> > shared library, it doesn't provide the linker search patch which is of
> > critical importance to get this stuff right.
> 
> Hmm...
> But what for is that search path?
> As far as I understand, dpkg-shlibdeps should just get NEEDED sonames, and 
> match those against available shlibs files.
> 
> And that is what code actually does. Path information is used only if 
> something is not found in this way - that means, package that provides the 
> library does not provide shlibs data, which is a bug anyway.

This isn't quite true I think. The current dpkg-shlibdeps code works
like this:

1) use "ldd <binary>" to find the paths to the linked libraries
2) use "objdump -p <binary>" to actually check which of this libraries
   are listed as NEEDED (Are there cases where ldd lists
   libraries that are not NEEDED?)
3) check the shlibs.local and shlibs.overides files for matches
4) for remaining libraries search the corresponding package with
   dpkg --search <path>
   Here the ldd information is used!
5) check the shlibs files of the packages identified

>From reading the source code of dpkg-cross' version of dpkg-shlibdeps
it works like this:

c1) like 2)
c2) like 3)
c3) determine the path to the library by just prepending $crossroot or
    $crossroot64 to it (both variables which can be set by the user)
c4) like 4)
c5) like 5)

I don't see how the current way this works can deal with several
library directories like /lib /usr/lib /usr/X11R6/lib. But maybe I'm
missing something?

> So looks it is safe to remove any path processing from dpkg-slibdeps, and 
> use only objdump. If something breaks, it should be fixed elsewhere (i.e. 
> proper shlibs data added to packages).

If we don't use the path information from ldd there are several ways to
go:
1) use "dpkg --search" but only with the library name from objdump, not
   with the full path.
   Questions: - Are there cases where the library name from objdump isn't
                actually the filename of the library?
	      - How do we decide wether a found file is really a usable
	        library? (parse /etc/ld.so.conf?)
2) we could try to use the ldconfig cache to make to work of ldd for
   ourself.
   Questions: - Is this really an advantage? Or has the cache the same
                problems ldd has?
3) we could parse /etc/ld.so.conf and search for the libraries ourself.
   this is essentially a more general version of the current way
   dpkg-cross works AFAICS
4) we could just parse _all_ shlib files, perhaps even generating a cache
   from them.
   Questions: - Seems a complex solution (if it uses caching). Is any of
                the simpler solutions feasible?
              - How slow is this?

Comments and corrections welcome.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/