Re: debian/rules and wrong run-time library

[Bill Moseley <moseley@hank.org>]

On Wed, May 17, 2003 at 11:52:47 +0200, Andreas Metzler wrote:

> >>> dpkg-shlibdeps: warning: could not find any packages for
> >>> /usr/local/lib/libswish-e.so.2 (libswish-e.so.2)
> >>> 
> >>> dpkg-shlibdeps: warning: unable to find dependency information for shared
> >>> library libswish-e (soname 2, path /usr/local/lib/libswish-e.so.2,
> >>> dependency field Depends)
> >> [...]
> 
> >> You are probably looking for something like
> >> dh_shlibdeps -ldebian/libswish-e/usr/lib

> > If that's the case then I would need to say that libswish-e is not a
> > dependency, or a dependency that is me by the swish-e package
> > itself.  Is that possible?
> 
> Yes. dh_shlibdeps is smart enough to recognize this, but you have to
> use the correct -l option.

Well, I'm not so sure that's related to my problem.

I just spent a few hours looking at some scary Perl, so I might have missed something. 
But, my situation is that this package builds both the library *and* a binary that links to 
that library.  That presents a few problems:

First, if bulding the package with debian/rules binary AND the package has not yet been 
installed, then the library is also not installed.  In that case ldd reports:

  $ ldd debian/swish-e/usr/bin/swish-e 
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4001b000)
        libswish-e.so.2 => not found
        ...

And thus you would see:

  $ dh_shlibdeps 
  dpkg-shlibdeps: warning: could not find path for libswish-e.so.2

Which is a different from the message I posted, but can be solved by the -l option you
recommended to set LD_LIBRARY_PATH.

But, that's still doesn't help because then ldd reports the path of the current location:

  $ LD_LIBRARY_PATH=debian/swish-e/usr/lib ldd debian/swish-e/usr/bin/swish-e 
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4001b000)
        libswish-e.so.2 => debian/swish-e/usr/lib/libswish-e.so.2 (0x400fc000)
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ...

That's no good because dpkg-shlibsdeps uses dpkg --search to lookup package names based on 
file names found in the ldd output.

That results in:

  $ dh_shlibdeps -ldebian/swish-e/usr/lib
  dpkg-shlibdeps: warning: could not find any packages for 
  /home/moseley/b/x/swish-e-2.3.6/debian/swish-e/usr/lib/libswish-e.so.2 (libswish-e.so.2)

as seen here:

  $ dpkg --search /home/moseley/b/x/swish-e-2.3.6/debian/swish-e/usr/lib/libswish-e.so.2
  dpkg: /home/moseley/b/x/swish-e-2.3.6/debian/swish-e/usr/lib/libswish-e.so.2 not found.

what it needs to do is:

  $ dpkg --search /usr/lib/libswish-e.so.2
  swish-e: /usr/lib/libswish-e.so.2

But, again, libswish-e.so.2 hasn't been installed yet so dpkg --search isn't going to find 
it anyway.  So I don't understand how -l can ever work.

dpkg-shlibdeps assumes that any libraries listed with ldd (or objdump) are already
installed, and that's not the case here.  The swish-e (upstream) package builds a library
and then builds a binary linked against that libraray.

Is it not possible to install a library and binary at the same time?

So back to the original problem, which was:

  dpkg-shlibdeps: warning: unable to find dependency information for shared library 
   libswish-e (soname 2, path , dependency field Depends)

And the reasons are:  

 1) the package swish-e has not been installed yet so no library dependency info exists
 2) there is not libswish-e package in Debian, so there's no point in making
    the swish-e package depend on it.

Anyway, I guess all I'm looking for is a way to supress that message from dpkg-shlibdeps.  I
did not see any way to do that by looking through the dpkg-shlibdeps Perl script.

I thought I could just hard-code the dependencies in debian/swish-e.substvars and remove
the call to dh_shlibdeps, but something removes swish-e.substvars.

So it looks like the solution is to hard-code the Depends: into the control file.  Will that 
break anything?



-- 
Bill Moseley
moseley@hank.org