Re: maserver: Dynamic libraries inside a program package

[Justin Pryzby <justinpryzby@users.sourceforge.net>]

On Tue, Feb 01, 2005 at 02:31:27AM +0100, Miriam Ruiz wrote:
> Hi,
Hiya,

> Now running lintian...
> E: maserver:
> sharedobject-in-library-directory-not-actually-a-shlib
> usr/lib/libmaserver.so.1.0
> Finished running lintian.
Try lintian -i: you'll see this type of thing:

  A shared object was identified in a library directory
  (i.e. a directory in the standard linker path) which
  doesn't have a SONAME.  This is usually an error.

(From http://lintian.debian.org/reports/Tsharedobject-in-library-directory-not-actually-a-shlib.html)

So, you need to edit the build system (or ask upstream) to
make gcc have an option like "-Wl,-soname,libmaserver.so.1".

> I can move to /usr/lib/maserver/* and that solves lintian
> error, but the program wouldn't locate it in runtime
> execution (unless i added a starting script exporting
> where to look for dynamic libraries).
Or rpath, which you don't want or need (rpath is used when
generating a binary, and it adds a directory in which to
look for depended-on shared librarys).

> I don't think linking statically the dynamic library is an
> opcion, because i feel that the plugins use it as well as
> the program, and I'd finally have it in every binary.
Right.

> Any suggestions? Thanks in advance for your help.
You should also edit the line with "dh_shlibdeps".  You'll
notice that if you unintall the package and then build it,
this line will generate a warning.  That's debhelper trying
to figure out "what package provides this shared library".
Oftentimes, its a different package.  The -l option to
dh_shlibdeps tells it where to look for the libraries when a
given package includes shared libraries as well as libraries
that depend on them.

> Link to dynamic library: usr/lib/maserver.so ->
> usr/lib/maserver.so.1.0
Also, do you actually need that link?  Hmm.  Its not a bad
idea, I guess, but will any other packages Build-Depend on
maserver?  More typically, binaries are in one package, and
libraries in another package (on which the binary package
depends), and then a development package (libfoo-dev)
includes shared libraries (sometimes) as well as the
libfoo.so => libfoo.so.0 symlink (which is only needed such
that the linker can go from -lfoo to libfoo.so).  

Cheers,
Justin