Naming Conventions
Neither the link-editor nor the runtime linker interprets any file by virtue of its file name. All files are inspected to determine their ELF type (see ELF Header). This information enables the link-editor to deduce the processing requirements of the file. However, shared objects usually follow one of two naming conventions, depending on whether they are being used as part of the compilation environment or the runtime environment.
When used as part of the compilation environment, shared objects
are read and processed by the link-editor. Although these shared objects can
be specified by explicit file names as part of the command passed to the
link-editor, the -l
option is usually used to take advantage
of the link-editor's library search facilities. See Shared Object Processing.
A shared object that is applicable to this link-editor processing, should be
designated with the prefix lib
and the suffix
.so
. For example,
/lib/libc.so
is the shared object
representation of the standard C library made available to the compilation
environment. By convention, 64-bit shared objects are placed in a
subdirectory of the lib
directory called
64
. For example, the 64-bit counterpart
of /lib/libc.so.1
, is
/lib/64/libc.so.1
.
When used as part of the runtime environment, shared objects are read and processed by the runtime linker. To allow for change in the exported interface of the shared object over a series of software releases, provide the shared object as a versioned file name.
A versioned file name commonly takes the form of a .so
suffix followed by a version number. For example,
/lib/libc.so.1
is the shared object
representation of version one of the standard C library
made available to the runtime environment.
If a shared object is never intended for use within a
compilation environment, its name might drop the conventional
lib
prefix. Examples of shared objects that
fall into this category are those used solely with
dlopen
(3C). A suffix of .so
is
still recommended to indicate the actual file type. In addition, a version
number is strongly recommended to provide for the correct binding of the
shared object across a series of software releases. Interfaces and Versioning
describes versioning in more detail.
Note:
The shared object name used in adlopen
(3C) is usually represented as a
simple file name, that has no '/' in
the name. The runtime linker can then use a set of rules to locate
the actual file. See Preloading Additional Objects for more details.