Chapter 10. Files
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
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.
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
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
directory. Such files are exempt from the rules that govern
ordinary shared libraries, except that they must not be installed executable and should be
Packages containing shared libraries that may be linked to by other packages' binaries, but
which for some compelling reason can not be installed in
directory, may install the
shared library files in subdirectories of the
directory, in which case they should
arrange to add that directory in
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
to do their linking. The latest
GNU libtools (>= 1.3a) can take advantage of the metadata in the installed
files). The main advantage of
files is that it allows
and subsequently access metadata with respect to the libraries it builds.
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
Packages that use
to create shared libraries should include the
files in the
package, unless the package relies on
library, in which case the
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.
You might also want to use the options
on both shared libraries and executables, and
on static libraries.
A common example are the so called plug ins , internal shared objects that are dynamically loaded by pro
is fully capable of linking against shared libraries which don't have
files, as it is a
mere shell script it can add considerably to the build time of a
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
version 1.4 (and to a lesser extent
version 1.3), the
files also store information about inter library
dependencies which cannot necessarily be derived after the
file is deleted.