Chapter 10. Files

79

this option enforces symbol resolution at build time, a missing library reference will be caught

early as a fatal build error.

All installed shared libraries should be stripped with

strip   strip unneeded

your lib

(The option

  strip unneeded

makes

strip

remove only the symbols which aren't needed

for relocation processing.) Shared libraries can function perfectly well when stripped, since the

symbols for dynamic linking are in a separate part of the ELF object file.

1

Note that under some circumstances it may be useful to install a shared library unstripped, for

example when building a separate package to support debugging.

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

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.

An ever increasing number of packages are using

libtool

to do their linking. The latest

GNU libtools (>= 1.3a) can take advantage of the metadata in the installed

libtool

archive

files (

*.la

files). The main advantage of

libtool

's

.la

files is that it allows

libtool

to store

and subsequently access metadata with respect to the libraries it builds.

libtool

will search

for those files, which contain a lot of useful information about a library (such as library depen 

dency information for static linking). Also, they're essential for programs using

libltdl

.

3

Packages that use

libtool

to create shared libraries should include the

.la

files in the

 dev

package, unless the package relies on

libtool

's

libltdl

library, in which case the

.la

files

must go in the run time library package.

You must make sure that you use only released versions of shared libraries to build your pack 

ages; otherwise other users will not be able to run your binaries properly. Producing source

packages that depend on unreleased compilers is also usually a bad idea.

1

You might also want to use the options

  remove section=.comment

and

  remove section=.note

on both shared libraries and executables, and

  strip debug

on static libraries.

2

A common example are the so called  plug ins , internal shared objects that are dynamically loaded by pro 

grams using

dlopen(3)

.

3

Although

libtool

is fully capable of linking against shared libraries which don't have

.la

files, as it is a

mere shell script it can add considerably to the build time of a

libtool

 using package if that shell script has to

derive all this information from first principles for each library every time it is linked. With the advent of

libtool

version 1.4 (and to a lesser extent

libtool

version 1.3), the

.la

files also store information about inter library

dependencies which cannot necessarily be derived after the

.la

file is deleted.