|This article relies on references to primary sources. (March 2011)|
In computing, a dynamic linker is the part of an operating system (OS) that loads (copies from persistent storage to RAM) and links (fills jump tables and relocates pointers) the shared libraries needed by an executable at run time, that is, when it is executed. The specific operating system and executable format determine how the dynamic linker functions and how it is implemented.
Linking is often referred to as a process that is performed at compile time of the executable, while a dynamic linker is in actuality a special loader that loads external shared libraries into a running process and then binds those shared libraries dynamically to the running process. This is also called dynamic or late linking.
Dynamic-link library, or DLL, is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. These libraries usually have the file extension DLL, OCX (for libraries containing ActiveX controls), or DRV (for legacy system drivers). The file formats for DLLs are the same as for Windows EXE files – that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bit Windows. As with EXEs, DLLs can contain code, data, and resources, in any combination.
Data files with the same file format as a DLL, but with different file extensions and possibly containing only resource sections, can be called resource DLLs. Examples of such DLLs include icon libraries, sometimes having the extension ICL, and font files, having the extensions FON and FOT.
ELF-based Unix-like systems
In most Unix-like systems that use ELF for executable images and dynamic libraries, most of the machine code that makes up the dynamic linker is actually an external executable that the operating system kernel loads and executes first in a process address space newly constructed as a result of an exec or posix_spawn call. At compile time, the path of the dynamic linker that should be used is embedded into the executable's
.interp section. The operating system kernel reads this while creating the new process then loads and executes this other executable binary. The dynamic linker then loads the initial executable image and all the dynamically-linked libraries on which it depends, and starts the executable. In Unix-like operating systems using ELF, dynamically-loaded shared libraries can be identified by the filename suffix .so (shared object).
The dynamic linker can be influenced into modifying its behavior during either the program's execution or the program's linking. Examples of this can be seen in the run-time linker manual pages for various Unix-like systems. A typical modification of this behavior is the use of the LD_LIBRARY_PATH and LD_PRELOAD environment variables. These variables adjust the runtime linking process by searching for shared libraries at alternate locations and by forcibly loading and linking libraries that would otherwise not be, respectively. See, for example, zlibc also known as uncompress.so (and not to be confused with the zlib compression library ). This LD_PRELOAD hack facilitates transparent decompression, that is, reading of pre-compressed (gzipped) file data on BSD and Linux systems, as if the files were not compressed — essentially allowing a user to pretend the native filesystem of the computer supported transparent compression, although with some caveats. The mechanism is flexible allowing trivial adaptation of the same code to perform additional or alternate processing of data during the file read, prior to the provision of said data to the user process which has requested it.
The GNU/Linux based operating systems implement a dynamic linker model where a portion of the executable includes a very simple linker stub which causes the operating system to load an external library into memory. This linker stub is added at compile time for the target executable. The linker stub's purpose is to load the real dynamic linker machine code into memory and start the dynamic linker process by executing that newly loaded dynamic linker machine code. While the design of the operating system is to have the executable load the dynamic linker before the target executable's main function is started, it however is implemented differently. The operating system knows the location of the dynamic linker and in turn loads that in memory during the process creation. Once the executable is loaded into memory, the dynamic linker is already there and linker stub simply executes that code. The reason for this change is that the ELF binary format was designed for multiple Unix-like operating systems and not just the GNU/Linux operating system.
OS X and iOS
The Apple Darwin operating system, and the OS X and iOS operating systems built atop it, implement a dynamic linker model where most of the machine code that makes up the dynamic linker is actually an external executable that the operating system kernel loads and executes first in a process address space newly constructed as a result of an exec or posix_spawn call. At compile time an executable has the path of the dynamic linker that should be used embedded into one of the Mach-O load commands. The operating system kernel reads this while creating the new process and, in turn, loads and then executes this other executable binary. The dynamic linker not only links the target executable to the shared libraries but also places machine code functions at specific address points in memory that the target executable knows about at link time. When an executable wishes to interact with the dynamic linker, it simply executes the machine-specific call or jump instruction to one of those well-known address points. The executables on the OS X and iOS platforms often interact with the dynamic linker during the execution of the process; it is even known that an executable might interact with the dynamic linker, causing it to load more libraries and resolve more symbols, hours after it initially launches. The reason that an OS X or iOS program interacts with the dynamic linker so often is due both to Apple's Cocoa and Cocoa Touch APIs and Objective-C, the language in which they are implemented (see their main articles for more information.) On the Darwin-based operating systems, the dynamic loaded shared libraries can be identified either by the filename suffix .dylib or by its placement inside the bundle for a framework.
The dynamic linker can be coerced into modifying some of its behavior; however, unlike other Unix-like operating systems, these modifications are hints that can be (and sometimes are) ignored by the dynamic linker. Examples of this can be seen in dyld's manual page. A typical modification of this behavior is the use of the DYLD_FRAMEWORK_PATH and DYLD_PRINT_LIBRARIES environment variables. The previously-mentioned variables adjust the executables' search path for the shared libraries, while another displays the names of the libraries as they are loaded and linked.
XCOFF-based Unix-like systems
In Unix-like operating systems using XCOFF , dynamically-loaded shared libraries the filename suffix .a.
The dynamic linker can be influenced into modifying its behavior during either the program's execution or the program's linking. A typical modification of this behavior is the use of the LIBPATH environment variable. This variable adjusts the runtime linking process by searching for shared libraries at alternate locations and by forcibly loading and linking libraries that would otherwise not be, respectively.
OS/360 and successors
Dynamic linking from Assembler language programs in IBM OS/360 and its successors is done typically using a LINK macro instruction containing a Supervisor Call instruction that activates the operating system routines that makes the library module to be linked available to the program. Library modules may reside in a "STEPLIB" or "JOBLIB" specified in control cards and only available to a specific execution of the program, in a library included in the LINKLIST in the PARMLIB (specified at system startup time), or in the "link pack area" where specific reentrant modules are loaded at system startup time.
- Microsoft Corporation. "Creating a Resource-Only DLL". Microsoft Developer Network Library.
- Solaris 10 User Commands Reference Manual: Solaris dynamic linker/loader –
- Linux Programmer's Manual – Administration and Privileged Commands –
- FreeBSD General Commands Manual: FreeBSD dynamic linker/loader –
- NetBSD General Commands Manual: NetBSD dynamic linker/loader –
- OpenBSD General Commands Manual: OpenBSD dynamic linker/loader –
- "uncompress.so". delorie.com. Retrieved 2014-07-04.
- "zlibc.conf". delorie.com. Retrieved 2014-07-04.
- Understanding the Linux Kernel, O'REILLY, 3rd Edition, Chapter 20
- Darwin and Mac OS X General Commands Manual: Darwin/Mac OS X dynamic linker/loader –
- Apple Inc. "Open Source - Releases". apple.com. Retrieved 2014-07-04.
- Dynamic Linking and Loading, IECC.com
- Dynamic Linking in Linux and Windows, part one, Symantec.com
- Anatomy of Linux dynamic libraries, IBM.com