Bug#317082: Not just a dpkg bug
Hello people.
> > > 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
Looks so. I was mistaken.
>> 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?
In cross-compile environment created by dpkg-cross, all libraries are
installed in the same directory.
As for this directory being user-configurable, I believe it's a misfeature
came from old versions of dpkg-cross, which should be eventually fixed.
While it's there, depending on -arch-cross packages is unreliable, which
is something I wish to avoid.
> > 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?
I sometimes have to work with MontaVista toolchains. They to provide
cross-ldd tool that just implements the same library-searching logic for
non-native binaries as dynamic libker implements for native ones.
I don't know if this thing is free etc, but it could be easilly implemented
from scratch if we decide we need one.
> 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?
I believe this is *the* correct way.
If should be *much* faster than calling dpkg -S - just because dpkg -S
actually loads all *.list files, which is many times larger than *.shlibs
files.
As I side effect, this will allow to remove LD_LIBRARY_PATH thing from
dh_shlibdeps, which gives some unwanted effects when cross-compiling
packages (like finding cross version of libz.so.1 in LD_LIBRARY_PATH and
refusing to load native binaries that link against libz.so.1).
The only question is that is will *require* packages to provide valid
shlibs.local files. We may make an experiment: try to build entire archive
using dpkg-shlibdeps that is based on shlibs file checking only, and see
how many packages get different dependences.
One more question that came to mind right now: is it possible that more
than one installed package provides shlibs infomation for the same soname?
From the other hand, what is the wanted behaviour in this case?
> > 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?)
> Note that this method is used in the patch for #285857 which I'm
> currently evaluating for inclusion. So it seems the answer to
> question 1 is "no" (or else the patch in #285857 is useless)...
That patch fixes paths that dpkg -S will search.
That bug describes the following situation:
- objdump finds NEEDED libfoo.so.X
- ldd resolves that to /lib/libfoo.so.X.Y
- dpkg -S can't find /lib/libfoo.so.X.Y, because file existsing in dpkg's
database is /usr/lib/libfoo.so.X.Y; ldd finds it under /lib
because /usr/lib just a symlink to /lib under hurd (per bug reporter)
This has nothing to do about 'library name from objdump isn't actually the
filename of the library'.
As for that question, AFAIK library filename and soname are completely
unrelated. So there may be a soname 'ABCDE' that is provided by libxxx.so.
A binary linked against that library will get 'NEEDED ABCDE'. And dynamic
linker and ldd will find it, as long as there is 'ABCDE' symlink or file
in dynamic linker search path.
> > Yes. ldd will list all shared libraries pulled in by a binary,
> > regardless of whether they're NEEDED by the binary itself or just
> > NEEDED by one of the shared libraries it uses. For example:
>
> And also LD_PRELOAD'd libraries, et cetera (which may include
> fakeroot).
As far as I understand, dpkg-shlibdeps uses ldd only to get paths to
libraries. The list of the libraries is got using objdump.
Nikita
Reply to: