Chapter 8. Shared libraries

55

8.2 Run time support programs

If your package has some run time support programs which use the shared library you must

not put them in the shared library package. If you do that then you won't be able to install

several versions of the shared library without getting filename clashes.

Instead, either create another package for the runtime binaries (this package might typically be

named

libraryname

 runtime

; note the absence of the soversion in the package name), or if

the development package is small, include them in there.

8.3 Static libraries

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 in 

clude:

  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 up 

stream author(s)

8.4 Development files

The development files associated to a shared library need to be placed in a package called

librarynamesoversion

 dev

, or if you prefer only to support one development version at

a time,

libraryname

 dev

.

In case several development versions of a library exist, you may need to use

dpkg

's Conflicts

mechanism (see `Conflicting binary packages  

Conflicts

' on page

48

) 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 installed).

call  ldconfig  at this point. For a package that is being removed, prerm is called with all the files intact, so calling

ldconfig is useless. The other calls to  prerm  happen in the case of upgrade at a time when all the files of the old

package are on disk, so again calling  ldconfig  is pointless. postrm, on the other hand, is called with the  remove 

argument just after the files are removed, so this is the proper time to call  ldconfig  to notify the system of the

fact shared libraries from the package are removed. The postrm can be called at several other times. At the time

of  postrm purge ,  postrm abort install , or  postrm abort upgrade , calling  ldconfig  is useless because the

shared lib files are not on disk. However, when  postrm  is invoked with arguments  upgrade ,  failed upgrade ,

or  disappear , a shared lib may exist on disk under a temporary filename.