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 a dlopen(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.