[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
Packages containing shared libraries must be constructed with a little care to make sure that the shared library is always available. This is especially important for packages whose shared libraries are vitally important, such as the C library (currently libc6).
This section deals only with public shared libraries: shared libraries that are placed in directories searched by the dynamic linker by default or which are intended to be linked against normally and possibly used by other, independent packages. Shared libraries that are internal to a particular package or that are only loaded as dynamic modules are not covered by this section and are not subject to its requirements.
A shared library is identified by the SONAME attribute stored in its dynamic section. When a binary is linked against a shared library, the SONAME of the shared library is recorded in the binary's NEEDED section so that the dynamic linker knows that library must be loaded at runtime. The shared library file's full name (which usually contains additional version information not needed in the SONAME) is therefore normally not referenced directly. Instead, the shared library is loaded by its SONAME, which exists on the file system as a symlink pointing to the full name of the shared library. This symlink must be provided by the package. Run-time shared libraries, Section 8.1 describes how to do this. [56]
When linking a binary or another shared library against a shared library, the SONAME for that shared library is not yet known. Instead, the shared library is found by looking for a file matching the library name with .so appended. This file exists on the file system as a symlink pointing to the shared library.
Shared libraries are normally split into several binary packages. The SONAME symlink is installed by the runtime shared library package, and the bare .so symlink is installed in the development package since it's only used when linking binaries or shared libraries. However, there are some exceptions for unusual shared libraries or for shared libraries that are also loaded as dynamic modules by other programs.
This section is primarily concerned with how the separation of shared libraries into multiple packages should be done and how dependencies on and between shared library binary packages are managed in Debian. Libraries, Section 10.2 should be read in conjunction with this section and contains additional rules for the files contained in the shared library packages.
The run-time shared library must be placed in a package whose name changes
whenever the SONAME of the shared library changes. This allows
several versions of the shared library to be installed at the same time,
allowing installation of the new version of the shared library without
immediately breaking binaries that depend on the old version. Normally, the
run-time shared library and its SONAME symlink should be placed in
a package named librarynamesoversion
, where
soversion is the version number in the SONAME of the
shared library. See The shlibs
File Format,
Section 8.6.3 for detailed information on how to determine this version.
Alternatively, if it would be confusing to directly append soversion
to libraryname (if, for example, libraryname itself ends
in a number), you should use
libraryname-soversion
instead.
If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together. Be aware that this is not normally the case, and if the SONAMEs do not change together, upgrading such a merged shared library package will be unnecessarily difficult because of file conflicts with the old version of the package. When in doubt, always split shared library packages so that each binary package installs a single shared library.
Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the SONAME of the library and the corresponding name for the binary package containing the runtime shared library should change. Normally, this means the SONAME should change any time an interface is removed from the shared library or the signature of an interface (the number of parameters or the types of parameters that it takes, for example) is changed. This practice is vital to allowing clean upgrades from older versions of the package and clean transitions between the old ABI and new ABI without having to upgrade every affected package simultaneously.
The SONAME and binary package name need not, and indeed normally
should not, change if new interfaces are added but none are removed or changed,
since this will not break binaries linked against the old shared library.
Correct versioning of dependencies on the newer shared library by binaries that
use the new interfaces is handled via the shlibs system or via symbols
files (see deb-symbols(5)
).
The package should install the shared libraries under their normal names. For
example, the libgdbm3
package should install
libgdbm.so.3.0.0
as /usr/lib/libgdbm.so.3.0.0
. The
files should not be renamed or re-linked by any prerm
or
postrm
scripts; dpkg
will take care of renaming
things safely without affecting running programs, and attempts to interfere
with this are likely to lead to problems.
Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump.
The run-time library package should include the symbolic link for the
SONAME that ldconfig
would create for the shared
libraries. For example, the libgdbm3
package should include a
symbolic link from /usr/lib/libgdbm.so.3
to
libgdbm.so.3.0.0
. This is needed so that the dynamic linker (for
example ld.so
or ld-linux.so.*
) can find the library
between the time that dpkg
installs it and the time that
ldconfig
is run in the postinst
script.[57]
Any package installing shared libraries in one of the default library
directories of the dynamic linker (which are currently /usr/lib
and /lib
) or a directory that is listed in
/etc/ld.so.conf
[58]
must use ldconfig
to update the shared library system.
The package maintainer scripts must only call ldconfig
under these
circumstances:
When the postinst
script is run with a first argument of
configure, the script must call ldconfig
, and may
optionally invoke ldconfig
at other times.
When the postrm
script is run with a first argument of
remove, the script should call ldconfig
.
[59]
If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult.
It is recommended that supporting files and run-time support programs that do
not need to be invoked manually by users, but are nevertheless required for the
package to function, be placed (if they are binary) in a subdirectory of
/usr/lib
, preferably under
/usr/lib/
package-name. If the program or file is
architecture independent, the recommendation is for it to be placed in a
subdirectory of /usr/share
instead, preferably under
/usr/share/
package-name. Following the
package-name naming convention ensures that the file names change
when the shared object version changes.
Run-time support programs that use the shared library but are not required for
the library to function or files used by the shared library that can be used by
any version of the shared library package should instead be put in a separate
package. This package might typically be named
libraryname-tools
; note the absence of the
soversion in the package name.
Files and support programs only useful when compiling software against the library should be included in the development package for the library.[60]
The static library (libraryname.a
) is usually provided
in addition to the shared version. It is placed into the development package
(see below).
In some cases, it is acceptable for a library to be available in static form only; these cases include:
libraries for languages whose shared library support is immature or unstable
libraries whose interfaces are in flux or under development (commonly the case when the library's major version number is zero, or where the ABI breaks across patchlevels)
libraries which are explicitly intended to be available only in static form by their upstream author(s)
If there are development files associated with a shared library, the source
package needs to generate a binary development package named
librarynamesoversion-dev
, or if you prefer
only to support one development version at a time,
libraryname-dev
. Installing the development package
must result in installation of all the development files necessary for
compiling programs against that shared library.[61]
In case several development versions of a library exist, you may need to use
dpkg
's Conflicts mechanism (see Conflicting binary packages -
Conflicts, Section 7.4) to ensure that the user only installs
one development version at a time (as different development versions are likely
to have the same header files in them, which would cause a filename clash if
both were unpacked).
The development package should contain a symlink for the associated shared
library without a version number. For example, the libgdbm-dev
package should include a symlink from /usr/lib/libgdbm.so
to
libgdbm.so.3.0.0
. This symlink is needed by the linker
(ld
) when compiling packages, as it will only look for
libgdbm.so
when compiling dynamically.
If the package provides Ada Library Information (*.ali
) files for
use with GNAT, these files must be installed read-only (mode 0444) so that GNAT
will not attempt to recompile them. This overrides the normal file mode
requirements given in Permissions
and owners, Section 10.9.
Typically the development version should have an exact version dependency on the runtime library, to make sure that compilation and linking happens correctly. The ${binary:Version} substitution variable can be useful for this purpose. [62]
If a package contains a binary or library which links to a shared library, we
must ensure that when the package is installed on the system, all of the
libraries needed are also installed. This requirement led to the creation of
the shlibs system, which is very simple in its design: any package
which provides a shared library also provides information on the
package dependencies required to ensure the presence of this library, and any
package which uses a shared library uses this information to determine
the dependencies it requires. The files which contain the mapping from shared
libraries to the necessary dependency information are called
shlibs
files.
When a package is built which contains any shared libraries, it must provide a
shlibs
file for other packages to use. When a package is built
which contains any shared libraries or compiled binaries, it must run dpkg-shlibdeps
on these to determine the libraries used and hence the dependencies needed by
this package.[63]
In the following sections, we will first describe where the various
shlibs files are to be found, then how to use
dpkg-shlibdeps
, and finally the shlibs file format
and how to create them if your package contains a shared library.
There are several places where shlibs files are found. The
following list gives them in the order in which they are read by dpkg-shlibdeps
.
(The first one which gives the required information is used.)
debian/shlibs.local
This lists overrides for this package. This file should normally not be used,
but may be needed temporarily in unusual situations to work around bugs in
other packages, or in unusual cases where the normally declared dependency
information in the installed shlibs
file for a library cannot be
used. This file overrides information obtained from any other source.
/etc/dpkg/shlibs.override
This lists global overrides. This list is normally empty. It is maintained by the local system administrator.
DEBIAN/shlibs
files in the "build directory"
When packages are being built, any debian/shlibs
files are copied
into the control information file area of the temporary build directory and
given the name shlibs
. These files give details of any shared
libraries included in the same package.[64]
/var/lib/dpkg/info/*.shlibs
These are the shlibs
files corresponding to all of the packages
installed on the system, and are maintained by the relevant package
maintainers.
/etc/dpkg/shlibs.default
This file lists any shared libraries whose packages have failed to provide
correct shlibs
files. It was used when the shlibs
setup was first introduced, but it is now normally empty. It is maintained by
the dpkg maintainer.
dpkg-shlibdeps
and the shlibs
files
Put a call to dpkg-shlibdeps
into your debian/rules
file. If your package contains only
compiled binaries and libraries (but no scripts), you can use a command such
as:
dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \ debian/tmp/usr/lib/*
Otherwise, you will need to explicitly list the compiled binaries and libraries.[65]
This command puts the dependency information into the
debian/substvars
file, which is then used by
dpkg-gencontrol
. You will need to place a
${shlibs:Depends} variable in the Depends field in
the control file for this to work.
If you have multiple binary packages, you will need to call
dpkg-shlibdeps
on each one which contains compiled libraries or
binaries. In such a case, you will need to use the -T option to
the dpkg utilities to specify a different substvars
file.
If you are creating a udeb for use in the Debian Installer, you will need to
specify that dpkg-shlibdeps
should use the dependency line of type
udeb by adding the -tudeb option[66]. If there is no dependency line
of type udeb in the shlibs
file,
dpkg-shlibdeps
will fall back to the regular dependency line.
For more details on dpkg-shlibdeps
, please see dpkg-shlibdeps
-
calculates shared library dependencies, Section C.1.4 and
dpkg-shlibdeps(1)
.
shlibs
File Format
Each shlibs
file has the same format. Lines beginning with
# are considered to be comments and are ignored. Each line is of
the form:
[type: ]library-name soname-version dependencies ...
We will explain this by reference to the example of the zlib1g
package, which (at the time of writing) installs the shared library
/usr/lib/libz.so.1.1.3
.
type is an optional element that indicates the type of package for which the line is valid. The only type currently in use is udeb. The colon and space after the type are required.
library-name is the name of the shared library, in this case libz. (This must match the name part of the soname, see below.)
soname-version is the version part of the soname of the library. The soname is the thing that must exactly match for the library to be recognized by the dynamic linker, and is usually of the form name.so.major-version, in our example, libz.so.1.[67] The version part is the part which comes after .so., so in our case, it is 1. The soname may instead be of the form name-major-version.so, such as libdb-4.8.so, in which case the name would be libdb and the version would be 4.8.
dependencies has the same syntax as a dependency field in a binary package control file. It should give details of which packages are required to satisfy a binary built against the version of the library contained in the package. See Syntax of relationship fields, Section 7.1 for details.
In our example, if the first version of the zlib1g package which contained a minor number of at least 1.3 was 1:1.1.3-1, then the shlibs entry for this library could say:
libz 1 zlib1g (>= 1:1.1.3)
The version-specific dependency is to avoid warnings from the dynamic linker about using older shared libraries with newer binaries.
As zlib1g also provides a udeb containing the shared library, there would also be a second line:
udeb: libz 1 zlib1g-udeb (>= 1:1.1.3)
shlibs
file
If your package provides a shared library, you need to create a
shlibs
file following the format described above. It is usual to
call this file debian/shlibs
(but if you have multiple binary
packages, you might want to call it
debian/shlibs.package
instead). Then let
debian/rules
install it in the control information file area:
install -m644 debian/shlibs debian/tmp/DEBIAN
or, in the case of a multi-binary package:
install -m644 debian/shlibs.package debian/package/DEBIAN/shlibs
An alternative way of doing this is to create the shlibs
file in
the control information file area directly from debian/rules
without using a debian/shlibs
file at all,[68] since the
debian/shlibs
file itself is ignored by
dpkg-shlibdeps
.
As dpkg-shlibdeps
reads the DEBIAN/shlibs
files in
all of the binary packages being built from this source package, all of the
DEBIAN/shlibs
files should be installed before
dpkg-shlibdeps
is called on any of the binary packages.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
Debian Policy Manual
version 3.9.3.1, 2012-03-13