Shared libraries contain an object (i.e. a module which can be loaded and executed by the system loader) with a special structure (a “shared object”). One of the characteristics of shared objects is that they can be dynamically loaded during program execution.
List of required objects
A shared object can specify other objects which are necessary in order for it to be executed. These objects are loaded at the same time as a shared object is loaded and are considered during resolution of unresolved external references. Here again, each of these objects can specify other required objects, so that chains are formed.
Name spaces
When a shared object is loaded, other dynamically loaded shared objects are not accessed unless they are included in the list of required objects.
An exception here is the context in which the program was loaded on startup (and all the objects which were dynamically loaded at that time).
This causes the name spaces to be partitioned.
Search sequence
The search for shared objects during program execution is controlled through the environment variable LD_LIBRARY_PATH, in which different directories can be specified which the system will search through in the specified sequence, looking for the shared objects which are to be loaded.
Resolution of external references
When a shared object is loaded, any unresolved external references are initially resolved from the primary load context. The current shared object is then included and finally the objects which were loaded as required objects. (This is a simplified version. Full details are provided in the interfaces descriptions of dlopen() and dlsym() in the corresponding Unix manuals).
As the external references within a shared object are not resolved, a function which exists in a shared object can be overwritten by a function of the primary load context (this is not possible in LLMs!).
Naming convention
Shared libraries always begin with the prefix lib and end with the suffix .so, for example, libhello.so. Often a name also has a version suffix for the co-existence and unambiguous assignment of different interface versions, for example, libXm.so.1.2.