Dynamic Library

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. 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 executableSome older systems, e.g., Burroughs MCP, Multics, also have a single format 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''.

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

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

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. 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

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

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

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). 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

Dynamic linking was originally developed for the Multics operating system, starting in 1964, and the MTS ( Michigan Terminal System), built in the late 1960s.

Notes

References

Computer libraries
Operating system technology

Sources

* {{cite book, last=Levine, first=J.R., title=Linkers and Loaders, publisher=Elsevier Science, series=Operating Systems Series, year=2000, isbn=978-1-55860-496-4, url=https://books.google.com/books?id=Id9cYsIdjIwC, access-date=2025-02-02