View source for Dynamic linker

{{Short description|Part of a computer's operating system}}
{{primary sources|date=March 2011}}
In [[computing]], a '''dynamic linker''' is the part of an [[operating system]] that [[Loader (computing)|loads]] and [[Linker (computing)|links]] the [[shared libraries]] needed by an [[executable]] when it is executed (at "[[Run time (program lifecycle phase)|run time]]"), by copying the content of libraries from [[persistent storage]] to [[RAM]], filling [[jump table]]s and relocating [[Pointer (computer programming)|pointers]]. 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 when the executable is [[compile time|compiled]], while a dynamic linker is a special part of an operating system that loads external shared libraries into a running [[Process (computing)|process]] and then [[Dynamic dispatch|binds]] those shared libraries dynamically to the running process. This approach is also called '''dynamic linking''' or '''late linking'''.

== Implementations ==

=== Microsoft Windows ===
{{Main article|Dynamic-link library}}

[[Dynamic-link library]], or DLL, is [[Microsoft]]'s implementation of the [[shared library]] concept in the [[Microsoft Windows]] and [[OS/2]] [[operating system]]s. These libraries usually have the [[file extension]] <code>DLL</code>, <code>OCX</code> (for libraries containing [[ActiveX]] controls), or <code>DRV</code> (for legacy [[device driver|system drivers]]).  The file formats for DLLs are the same as for Windows [[EXE]] files{{snd}} 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 [[Machine code|code]], [[data (computing)|data]], and [[resource (Windows)|resources]], in any combination.

Data [[computer file|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 multi-language user interface libraries with extension <code>MUI</code>, [[icon (computing)|icon]] libraries, sometimes having the extension <code>ICL</code>, and [[typeface|font]] files, having the extensions <code>FON</code> and <code>FOT</code>.<ref>
{{cite web
|url=http://msdn.microsoft.com/en-US/library/24b2tcy0(v=VS.80).aspx
|title=Creating a Resource-Only DLL
|work=Microsoft Developer Network Library
|author=Microsoft Corporation
}}</ref>

===Unix-like systems using ELF, and Darwin-based systems===
In most [[Unix-like]] systems, most of the machine code that makes up the dynamic linker is actually an external executable that the operating system [[kernel (operating system)|kernel]] loads and executes first in a process address space newly constructed as a result of calling <code>[[exec (operating system)|exec]]</code> or <code>[[Spawn (computing)#POSIX spawn functions|posix_spawn]]</code> functions. At link time, the path of the dynamic linker that should be used is embedded into the executable image.

When an executable file is loaded, the operating system kernel reads the path of the dynamic linker from it and then attempts to load and execute this other executable binary; if that attempt fails because, for example, there is no file with that path, the attempt to execute the original executable fails. The dynamic linker then loads the initial executable image and all the dynamically-linked libraries on which it depends and starts the executable. As a result, the pathname of the dynamic linker is part of the operating system's [[application binary interface]].

====Systems using ELF====
In Unix-like systems that use [[Executable and Linkable Format|ELF]] for executable images and dynamic libraries, such as [[Solaris (operating system)|Solaris]], 64-bit versions of [[HP-UX]], [[Linux]], [[FreeBSD]], [[NetBSD]], [[OpenBSD]], and [[DragonFly BSD]], the path of the dynamic linker that should be used is embedded at link time into the <code>.interp</code> section of the executable's <code>PT_INTERP</code> segment.  In those systems, dynamically loaded shared libraries can be identified by the filename suffix <code>.so</code> (shared object).

The dynamic linker can be influenced into modifying its behavior during either the program's execution or the program's linking, and the examples of this can be seen in the run-time linker manual pages for various Unix-like systems.<ref>{{man|1|ld.so.1|Solaris|Solaris dynamic linker/loader}}</ref><ref>{{man|8|ld-linux.so|Linux||GNU libc dynamic linker/loader}}</ref><ref>{{man|1|rtld|FreeBSD|FreeBSD dynamic linker/loader}}</ref><ref>{{man|1|ld.elf_so|NetBSD|NetBSD dynamic linker/loader}}</ref><ref>{{man|1|ld.so|OpenBSD|OpenBSD dynamic linker/loader}}</ref> A typical modification of this behavior is the use of <code>LD_LIBRARY_PATH</code> and <code>LD_PRELOAD</code> [[environment variables]], which 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.  An example is zlibc,<ref>{{cite web |url=https://www.zlibc.linux.lu/ |url-status=dead |archive-url=https://web.archive.org/web/20000604085701/http://zlibc.linux.lu/ |archive-date=2000-06-04 |title=ZLIBC - Transparent access to compressed files}}</ref> also known as <code>uncompress.so</code>,{{Efn|Not to be confused with the [[zlib]] compression library.}} which facilitates transparent decompression when used through the <code>LD_PRELOAD</code> [[hack (computer science)|hack]]; consequently, it is possible to read pre-compressed (gzipped) file data on BSD and Linux systems as if the files were not compressed, essentially allowing a user to add transparent compression to the underlying filesystem, 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 that has requested it.<ref>{{cite web
 | url=http://www.delorie.com/gnu/docs/zlibc/zlibc.3.html 
 | title=uncompress.so 
 | website=delorie.com 
 | access-date=2014-07-04
}}</ref><ref>{{cite web
 | url=http://www.delorie.com/gnu/docs/zlibc/zlibc.conf.5.html 
 | title=zlibc.conf 
 | publisher=delorie.com 
 | access-date=2014-07-04
}}</ref>

==== macOS and iOS ====
In the Apple [[Darwin (operating system)|Darwin]] operating system, and in the [[macOS]] and [[iOS (Apple)|iOS]] operating systems built on top of it, the path of the dynamic linker that should be used is embedded at link time into one of the [[Mach-O]] load commands in the executable image.  In those systems, dynamically loaded shared libraries can be identified either by the filename suffix <code>.dylib</code> or by their placement inside the [[Bundle (macOS)|bundle]] for a framework.

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 macOS 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 a macOS or iOS program interacts with the dynamic linker so often is due both to Apple's [[Cocoa (API)|Cocoa]] and [[Cocoa Touch]] APIs and [[Objective-C]], the language in which they are implemented (see their main articles for more information).

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 <code>dyld</code>'s manual page.<ref>{{man|1|dyld|Darwin|Darwin/Mac OS X dynamic linker/loader}}</ref> A typical modification of this behavior is the use of the <code>DYLD_FRAMEWORK_PATH</code> and <code>DYLD_PRINT_LIBRARIES</code> environment variables. The former of the previously-mentioned variables adjusts the executables' search path for the shared libraries, while the latter displays the names of the libraries as they are loaded and linked.

Apple's macOS dynamic linker is an open-source project released as part of [[Darwin (operating system)|Darwin]] and can be found in the Apple's open-source <code>dyld</code> project.<ref>{{cite web|author=Apple Inc. |url=https://opensource.apple.com|title=Open Source - Releases |publisher=apple.com |access-date=2014-07-04}}</ref>

===XCOFF-based Unix-like systems===
<!-- yes, most of the wording is stolen from the section on ELF -->
In Unix-like operating systems using [[XCOFF]]<!-- actually I only know this for sure for AIX -->, such as [[AIX]], dynamically-loaded shared libraries use the filename suffix <code>.a</code><!-- just like usual static libraries -->.

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 <code>[[LIBPATH]]</code> [[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 [[OS/360 and successors|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.

=== Multics ===
In the [[Multics]] operating system all files, including executables, are [[Memory segmentation|segments]]. A call to a routine not part of the current segment will cause the system to find the referenced segment, in memory or on disk, and add it to the address space of the running process. Dynamic linking is the normal method of operation, and static linking (using the ''binder'') is the exception.

==Efficiency==
Dynamic linking is generally slower (requires more CPU cycles) than linking during compilation time,<ref>{{cite web|last=Xuxian|first=Jiang|url=https://www.csc2.ncsu.edu/faculty/xjiang4/csc501/readings/lec10-linkerloader.pdf|title=Operating Systems Principles: Linking and Loading|year=2009|access-date=2020-09-24|publisher=[[North Carolina State University]]}}</ref> as is the case for most processes executed at runtime. However, loading time can be reduced by using "lazy linking", a process in which calls to functions of a library are linked to the implementation (inside the library) only when the first call occurs; a side effect is that, once the program is loaded, the first call to a function would be slower, as the time to link to it was shifted from startup time to run time.

However, dynamic linking is often more space-efficient (on disk and in memory at runtime). When a library is linked statically, every process being run is linked with its own copy of the library functions being called upon. Therefore, if a library is called upon many times by different programs, the same functions in that library are duplicated in several places in the system's memory. Using shared, dynamic libraries means that, instead of linking each file to its own copy of a library at compilation time and potentially wasting memory space, only one copy of the library is ever stored in memory at a time, freeing up memory space to be used elsewhere.<ref name="LinuxDynamicLibraries">{{cite web|last=Jones|first=M.|url=https://developer.ibm.com/technologies/linux/tutorials/l-dynamic-libraries/|title=Anatomy of Linux dynamic libraries|date=2008-08-28|access-date=2020-09-24|publisher=[[IBM]]}}</ref> Additionally, in dynamic linking, a library is only loaded if it is actually being used.<ref>{{cite web|last=Sivilotti|first=Paul|url=http://web.cse.ohio-state.edu/~sivilotti.1/teaching/3903.recent/lectures/lecture27.pdf|title=Dynamic Linking and Loading|date=August 2012|access-date=2020-09-24|publisher=[[Ohio State University]]<!--Wikipedians do not use "The" as part of Ohio State's name; it is considered a marketing gimmick, and routinely deleted.-->}}</ref>

== See also ==
{{Portal|Computer programming}}

* [[Direct binding]]
* [[DLL Hell]]
* [[Dynamic loading]]
* [[Late binding]]
* [[prelink]]
* [[Dynamic dead code elimination]]

== Notes ==
{{Notelist}}

==References==
{{Reflist|30em}}

== Further reading ==
* {{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}} Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]

== External links ==
* [https://web.archive.org/web/20140906011931/http://www.iecc.com/linker/linker10.html Dynamic Linking and Loading], ''IECC.com''
* [https://community.broadcom.com/symantecenterprise/communities/community-home/librarydocuments/viewdocument?DocumentKey=d0e6af9a-2271-4aa1-b698-b09a1c103f9f&CommunityKey=1ecf5f55-9545-44d6-b0f4-4e4a7f5f5e68&tab=librarydocuments Dynamic Linking in Linux and Windows, part one], ''Symantec.com''
* [http://www.ibm.com/developerworks/library/l-dynamic-libraries/ Anatomy of Linux dynamic libraries], ''IBM.com''

{{Application binary interface}}

[[Category:Computer libraries]]
[[Category:Computer security exploits]]
[[Category:Compilers]]