Re: lintian: questions about shared libraries
On Wed, 15 Apr 1998, Christian Schwarz wrote:
> So, the question is now whether a shared library *must* set
> SONAME or not. If it must do so, the gdk-imlib1 package has a
> bug (and probably others, too); otherwise Lintian has a bug (in
> which case it would be good to hear of a better solution to
> recognize shared libraries).
yes, it must. From the ld manpage:
-soname name
When creating an ELF shared object, set the inter-
nal DT_SONAME field to the specified name. When an
executable is linked with a shared object which has
a DT_SONAME field, then when the executable is run
the dynamic linker will attempt to load the shared
object specified by the DT_SONAME field rather than
the using the file name given to the linker.
that means "gcc -o foo foo.c -lbar" will produce foo linked
against libbar.so, which is symlinked with libbar.so.x.y.z which
has a SONAME libbar.so.x, which is the file that
libbarX_x.y.z-w.deb will install. The symlink is installed by
libbar-dev_x.y.z-w.deb. Did I explain myself? The point is, if
the library doesn't have a SONAME field, its file name will be
used, and that means trouble, the way I see it.
> 2. The question I have is the exact file format of the `shlibs' control
> files. Most packages install shlibs files like this:
> libfoo 1 foo (>= 1.2.3-1)
from the wording on the packaging manual, I'd say that the first
field is the SONAME sans the .so.version part, but the example
given by Joey makes me think I'm wrong. The problem is, the
SONAME and the FILENAME doesn't have to match. That's what
ldconfig does. It scans the files for SONAMEs and builds a cache
filename -> SONAME.
Maybe Ian can shed some light here? (Did Ian wrote that part on
the packaging manual?)
Marcelo
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: