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

Re: building libkpathsea



Hi,

Norbert Preining <preining@logic.at> wrote:

> dpkg-shlibdeps: warning: could not find any packages for libkpathsea.so.4
> dpkg-shlibdeps: warning: unable to find dependency information for shared library libkpathsea (soname 4, path libkpathsea.so.4, dependency field Depends)

AFAICT, dpkg-shlibdeps works basically like this:
  - look for ELF files in the package build directory;
  - for each binary, find the libraries it needs; this info includes the
    SONAME of the library the binary was linked against (e.g.,
    libfoo.so.3);
  - find the file among /var/lib/dpkg/info/*.shlibs that declares the
    appropriate dependency for a binary linked with such a SONAME (e.g.,
    "libfoo3 (>= 1.12)").

So, it works because of this little database made of all these .shlibs
files in /var/lib/dpkg/info, which tell which package dependencies are
needed for each binary to find the shared libraries it was linked with.

And this database is collectively built by the maintainers of the
various library packages. Every package shipping a shared library has to
provide a debian/shlibs file that tells the dependencies needed for
packages linked against that library. AFAIU, this file is the one
installed by dpkg as /var/lib/dpkg/info/pacakge.shlibs to build the
database for shared library dependencies.

This works fine as long as you have the needed shlibs files installed in
/var/lib/dpkg/info/ at the time where dpkg-shlibdeps is run for a given
binary (this program, which is run by dh_shlibdeps, determines the
appropriate package dependencies needed for a binary by looking at the
libs it is linked against and looking them up in the database made of
/var/lib/dpkg/info/*.shlibs).

However, there is a tricky situation when the shared library is part of
a source package that also builds binaries linked against the library:
when dpkg-shlibdeps is run for these binaries, the correct .shlibs file
in /var/lib/dpkg/info/ will *not* be found, since it is still only known
as debian/shlibs for the package being built!

One way around this was to provide a shlibs.local file, but since a few
years, dh_shlibdeps provides the -l and -L options that allow easier
resolution of this little problem (see the EXAMPLES section of
dh_shlibdeps(1)).

I think this is what you need.

Policy chapter 8 (Shared libraries) is also a must-read, if you don't
know it by heart already. :-)

-- 
Florent



Reply to: