Shared library

"Shared object" redirects here. For the synchronization mechanism, see Monitor (synchronization).

A shared library is a library of executable code that is loaded in memory such that multiple executables (programs and other libraries) can use it at runtime.^[1][2][3]

In contrast, a static library is copied into an executable. A static library can be re-used (a form of sharing) in multiple executables, but each executable contains a copy of the library code instead of sharing a copy in memory with other executables. Although not true today, historically, all libraries were static.^[4] Although a shared library can have static linkage, such a library is not classified as a static library.

Often, a shared library is also a dynamic library; loaded by a dynamic linker which generally makes use of the library easier for the programmer than if it instead it had static linkage. A dynamic library need not be accessible to multiple executables (shared library) and a shared library need not be loaded at consumer runtime (dynamic library).

Memory sharing

Main article: Shared memory

Library code may be shared in memory by multiple processes and on disk. If virtual memory is used, processes would execute the same physical page of RAM mapped into the processes' different address spaces. This has advantages. For instance, on the OpenStep system, applications were often only a few hundred kilobytes in size and loaded quickly; most of their code was located in libraries already loaded for other purposes by the operating system.^{[citation needed]}

Programs can accomplish RAM sharing by using position-independent code, as in Unix, which leads to a complex but flexible architecture, or by using common virtual addresses, as in Windows and OS/2. These systems ensure that code has a high probability of being shared by various means, like pre-mapping the address space and reserving slots for each shared library. A third alternative is a single-level store with a single address space, as used by the IBM System/38 and its successors. This allows position-dependent code, with programs and libraries assigned a permanent address in that address space.

In some cases, different versions of shared libraries can cause problems, especially when libraries of different versions have the same file name and various applications are installed on a system, each requiring a specific version. This scenario is known as DLL hell, named after the Windows and OS/2 DLL files. Most modern operating systems after 2001 have clean-up methods to eliminate such situations or use application-specific "private" libraries.^[5]

Examples

The following commonly-used library technologies are both shared and dynamic in nature.

DLL

Windows uses the Portable Executable (PE) format for its dynamic-link library (DLL) technology.

SO

Linux, BSD, Solaris and other System V Release 4-based systems, use the Executable and Linkable Format (ELF) for the shared object (SO) technology; sometimes and more accurately called dynamic shared object (DSO).

DYLIB

Darwin-based operating systems, such as macOS and iOS, use the Mach-O format for .dylib files.

See also

• Loadable kernel module – Dynamically loadable module that extends a running operating system kernel