Chapter 8. Shared libraries

56

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.

8.5 Dependencies between the packages of the same library

Typically the development version should have an exact version dependency on the

runtime library, to make sure that compilation and linking happens correctly.

The

${Source Version}

substitution variable can be useful for this purpose.

8.6 Dependencies between the library and other packages   the

shlibs

system

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 dependen 

cies 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.

Thus, when a package is built which contains any shared libraries, it must provide a

shlibs

file for other packages to use, and 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.

6

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.

6

In the past, the shared libraries linked to were determined by calling

ldd

, but now

objdump

is used to do this.

The only change this makes to package building is that

dpkg shlibdeps

must also be run on shared libraries,

whereas in the past this was unnecessary. The rest of this footnote explains the advantage that this method gives.

We say that a binary

foo

directly uses a library

libbar

if it is explicitly linked with that library (that is, it uses

the flag

 lbar

during the linking stage). Other libraries that are needed by

libbar

are linked indirectly to

foo

,

and the dynamic linker will load them automatically when it loads

libbar

. A package should depend on the

libraries it directly uses, and the dependencies for those libraries should automatically pull in the other libraries.

Unfortunately, the

ldd

program shows both the directly and indirectly used libraries, meaning that the depen 

dencies determined included both direct and indirect dependencies. The use of

objdump

avoids this problem by

determining only the directly used libraries. A good example of where this helps is the following. We could up 

date

libimlib

with a new version that supports a new graphics format called dgf (but retaining the same major

version number). If we used the old

ldd

method, every package that uses

libimlib

would need to be recompiled

so it would also depend on

libdgf

or it wouldn't run due to missing symbols. However with the new system,

packages using

libimlib

can rely on

libimlib

itself having the dependency on

libdgf

and so they would not

need rebuilding.