Dynamic library
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
A dynamic library is a library that contains functions and data that can be consumed by a computer program at run-time as loaded from a file separate from the program executable. Dynamic linking or late binding allows for using a dynamic library by linking program library references with the associated objects in the library either at load-time or run-time. At program build-time, the linker records what library objects the program uses. When the program is run, a dynamic linker or linking loader associates program library references with the associated objects in the library.
A dynamic library can be linked at build-time to a stub for each library resource that is resolved at run-time.[1] Alternatively, a dynamic library can be loaded without linking to stubs.
Most modern operating systems use the same format for both a dynamic library and an executable[NB 1] which affords two main advantages: it necessitates only one loader, and it allows an executable file to be used as a shared library. Examples of file formats use for both dynamic library and executable files include ELF, Mach-O, and PE.
A dynamic library is called by different names in different contexts. In Windows and OS/2 the technology is called dynamic-link library. In Unix-like user space, it's called dynamic shared object (DSO), or usually just shared object (SO). In Linux kernel it's called loadable kernel module (LKM). In OpenVMS, it's called shareable image.[2]
As an alternative to dynamic linking, a static library is included into the program executable so that the library is not required at run-time.
Dynamic loading
[edit]Dynamic loading is the process of loading a dynamic library at run-time and also unloading a library. A load can be initiated implicitly or explicitly by a program. An implicit request occurs if the program is configured to automatically load the dynamic library and this is setup at link-time. Explicit requests are made by a program via operating system API calls. For instance, Windows provides LoadLibrary, LoadLibraryEx, FreeLibrary and GetProcAddress. POSIX-based systems, including most UNIX and UNIX-like systems, use dlopen, dlclose and dlsym.
A dynamic loader locates a dynamic library on request and implementation varies. Some loaders depend on the executable storing a full path to the library. Any change to the library name or location results in a run-time failure. More commonly, the library name without path information is stored in the executable, and the loader applies a search algorithm to find the file.
If a dynamic library that an program depends is unavailable (deleted, moved, renamed) or replaced with an incompatible version, the executable will fail at run-time. This is called dependency hell and on Windows DLL hell. Issues can be minimized by naming library files with a version number and by following versioning rules that require changing the version when an incompatible change is made.
Windows
[edit]For a custom DLL Windows checks the directory where it loaded the program; directories configured via SetDllDirectory(); the System32, System, and Windows directories; then the current working directory; and finally the directories specified by the PATH environment variable.[3] Applications written for the .NET Framework (since 2002), also check the Global Assembly Cache as the primary store of shared DLL files to remove the issue of DLL hell.
Originally, for COM, Windows would only query the registry to locate a DLL that provides an object class. Later, Windows allowed for loading from a DLL file co-located with the program executable.
To address "DLL hell", Windows applications are typically installed with private DLL files and the system prevents replacement of shared system DLLs with earlier versions.
OpenStep
[edit]OpenStep used a more flexible system, collecting a list of libraries from a number of known locations (similar to the PATH concept) when the system first starts. Moving libraries around causes no problems at all, although users incur a time cost when first starting the system.
Unix-like systems
[edit]Most Unix-like systems have a "search path" specifying file-system directories in which to look for dynamic libraries. Some systems specify the default path in a configuration file, others hard-code it into the dynamic loader. Some executable file formats can specify additional directories in which to search for libraries for a particular program. This can usually be overridden with an environment variable, although it is disabled for setuid and setgid programs, so that a user can't force such a program to run arbitrary code with root permissions. Developers of libraries are encouraged to place their dynamic libraries in places in the default search path. On the downside, this can make installation of new libraries problematic, and these "known" locations quickly become home to an increasing number of library files, making management more complex.
Prebinding
[edit]As an optimization, systems can compute the likely load address for each dynamic library on the system to minimize load-time when the library is needed. This optimization is known as prebinding and prelinking on macOS and Linux, respectively. IBM z/VM uses a similar technique, called Discontinuous Saved Segments (DCSS).[4] Disadvantages of this technique include the time required to compute the addresses each time a dynamic library changes, the inability to use address space layout randomization, and the requirement of sufficient virtual address space for use.
History
[edit]Dynamic linking was originally developed for the Multics operating system, starting in 1964, and the MTS (Michigan Terminal System), built in the late 1960s.[5]
Notes
[edit]- ^ Some older systems, e.g., Burroughs MCP, Multics, also have a single format
References
[edit]- ^ Microsoft (2021-10-29). "Walkthrough: Create and use a static library (C++)". learn.microsoft.com. Retrieved 2025-02-01.
Using a static library is a great way to reuse code. Rather than reimplementing the same routines in every app that requires the functionality, you write them one time in a static library and then reference it from the apps. Code linked from a static library becomes part of your app—you don't have to install another file to use the code.
- ^ "VSI OpenVMS Linker Utility Manual" (PDF). VSI. August 2019. Retrieved 2021-01-31.
- ^ "Dynamic-Link Library Search Order". Microsoft Developer Network Library. Microsoft. 2012-03-06. Archived from the original on 9 May 2012. Retrieved 2012-05-20.
- ^ IBM Corporation (2011). Saved Segments Planning and Administration (PDF). Retrieved Jan 29, 2022.
- ^ "A History of MTS". Information Technology Digest. 5 (5).
Sources
[edit]- Levine, J.R. (2000). Linkers and Loaders. Operating Systems Series. Elsevier Science. ISBN 978-1-55860-496-4. Retrieved 2025-02-02.