Dynamic Shared Objects

Dynamic Shared Object is the correct term for Shared Library has it covers the two concepts:

  • shared: this means the read-only part (i.e., the sharable part) of the object is loaded once in the physical memory but multiple instances can be mapped into different process (virtual) address spaces. Note this is true for any binary so the term shared is more the opposite of static (static libraries are archives of binary objects with a prepended symbol table to make linking faster/easier. When a static library is linked, referenced objects are included in the final binary so definitely not shared).
  • dynamic: this means the object linking is finalised, and in particular the relocation phase, at runtime either during the executable startup for real Shared Libraries or explicitly loaded and linked using dlopen() (or a similar function). In its second form, it is used for kernel modules, Kea hooks and many plugins and in general the unload operation is (or should be) supported, it is written in C or in C++ with C linkage (i.e., with extern "C") for exported entry points.

The confusion comes from the fact the structure and naming are the same on most system where any shared library can be explicitly loaded... Please note that libtool makes a difference with the -module link argument.

Dynamic Loader/Linker API

In all cases you can find 3 main routines and a helper:

  • a function to load (and link) a DSO returning an handle: dlopen(), LoadLibrary(), ...
  • a function to unload on the last reference a DSO: dlclose(), FreeLibrary(), ...
  • a function to find the actual address of a symbol from the handle to its DSO and its name: dlsym(), GetProcAddress(), ...
  • a helper to decode eventual errors: dlerror(), ...

OS X case

OS X shows 3 particularities:

  • the DSO name extension is not .so but .dylib. Of course the object name can be forced to what one wants, including the extension.
  • DSOs are split into dynamically linked shared libraries (real shared libraries), bundles (DSO which must be explicitly loaded) and frameworks (directories with resources, the equivalent for bundles to applications vs executables).
  • optionally a two-level namespace (where symbol name is a library name + the name inside the library) can be used in place of the usual flat namespace. Of course this is useless for explicitly loaded DSOs as symbol names are always related to a DSO.

To summary OS X is a BSD system where Dynamic Shared Objects and Shared Libraries are not the same.

Windows case

In Windows the main concept is the DSO, named locally Dynamic-Link Library (DLL). Shared Libraries are implemented as DLLs. Another specific point is the use of import and export tables for symbols which have to be externally visible (cf. the visibility).

Last modified 4 years ago Last modified on May 18, 2015, 2:27:19 PM