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

Re: How to link against non-public shared libraries?



On Tue, 13 Jul 2004, Milan Zamazal wrote:

> My package contains binaries using a common shared library, which is not
> intended to be used by other programs.  This is a regular shared
> library, not a plugin or other object to be explicitly loaded by the
> binaries, the binaries just normally link to it.
>
> Debian Policy says:
>
>      Shared object files (often `.so' files) that are not public libraries,
>      that is, they are not meant to be linked to by third party executables
>      (binaries of other packages), should be installed in subdirectories of
>      the `/usr/lib' directory.  Such files are exempt from the rules that
>      govern ordinary shared libraries, except that they must not be
>      installed executable and should be stripped.[2]
>
> So the shared library should be put into /usr/lib/SOMETHING/, which is
> of course a non-standard path for the linker.
>
> My question is: How to ensure properly that the binaries can find the
> library?  I can think of several solutions (putting the library into
> /usr/lib/, modifying /etc/ld.so.conf, using -rpath), but I'm not sure
> which of them is the right one.  I tried to RTFM and to find a similar
> case in another package, but without success.

The way I read it, this policy is to make clear that plugins should
not be put in /usr/lib, not to make things gratuitously complex.

The same policy says:

   Packages containing shared libraries that may be linked to by other
   packages' binaries, but which for some compelling reason can not be
   installed in /usr/lib directory, may install the shared library files
   in subdirectories of the /usr/lib directory, in which case they should
   arrange to add that directory in /etc/ld.so.conf in the package's
   post-installation script, and remove it in the package's post-removal
   script.

but this does not work for the Hurd, which does not use ld.so.conf.
So, this policy is old and should be changed.


The gettext package is similar. It has some "internal" libraries which
are only used by executables in the gettext package, but moving those
libraries out of /usr/lib would not be practical at all.



Reply to: