Linker (computing): Difference between revisions

Revision as of 03:04, 16 September 2022

Latest revision as of 21:37, 16 May 2025

(48 intermediate revisions by 30 users not shown)

Line 1:

{{Short description|ComputerProgram program whichthat combines multipleintermediate objectbuild files into aan singleexecutable file}}

{{Use dmy dates|date=January 2020|cs1-dates=y}}

[[File:Linker.svg|thumb|An illustration of the linking process. Object files and [[static library|static libraries]] are assembled into a new library or executable]]

In [[computing]], aA '''linker''' or '''link editor''' is a computer [[System software|systemcomputer program]] that takescombines one or moreintermediate [[objectsoftware filebuild]]s (generatedfiles bysuch aas [[compilerobject file|object]] or anand [[assemblerlibrary (computing)|assemblerlibrary]]) and combines themfiles into a single [[executable]] file, such as a program or library. A linker is often part of a [[librarytoolchain]] that includes a [[compiler]] and/or [[assembler (computing)|libraryassembler]] file,that orgenerates anotherintermediate "object"files filethat the linker processes. The linker may be integrated with other toolchain [[development tool|tools]] such that the user does not interact with the linker directly.

A simpler version that writes its [[Input/output|output]] directly to [[Computer memory|memory]] is called the ''loader'', though [[loader (computing)|loading]] is typically considered a separate process.<ref name="IBM_1972"/><ref name="Barron_1978_Consolidator"/>

== Overview ==

Computer programs typically are composed of several parts or modules; these parts/modules do not need to be contained within a single [[object file]], and in such cases refer to each other by means ofusing [[debugsymbol symbol(computing)|symbols]] as addresses into other modules, which are mapped into memory addresses when linked for execution. Typically, an object file can contain three kinds of symbols:

While the process of linking is meant to ultimately combine these independent parts, there are many good reasons to develop those separately at the [[Source code|source]]-level. Among these reasons are the ease of organizing several smaller pieces over a [[Monolithic codebase|monolithic]] whole and the ability to better define the purpose and responsibilities of each individual piece, which is essential for managing complexity and increasing long-term maintainability in [[software architecture]].

Typically, an object file can contain three kinds of symbols:

* defined "external" symbols, sometimes called "public" or "entry" symbols, which allow it to be called by other modules,

Line 16 ⟶ 20:

For most compilers, each object file is the result of compiling one input source code file. When a program comprises multiple object files, the linker combines these files into a unified executable program, resolving the symbols as it goes along.

Linkers can take objects from a collection called a ''[[library (computing)|library]]'' or [[runtime library]]. Most linkers do not include all the wholeobject files in a [[static library]] in the output executable; they include only thethose object files{{clarify|date=March 2020}}from the library that are referenced by other object files or libraries directly or indirectly. But for a [[shared libraries|shared library]], the entire library has to be loaded during runtime as it is not known which functions or methods will be called during runtime. Library linking may thus be an iterative process, with some referenced modules requiring additional modules to be linked, and so on. Libraries exist for diverse purposes, and one or more system libraries are usually linked in by default.

The linker also takes care of arranging the objects in a program's [[address space]]. This may involve ''relocating'' code that assumes a specific [[base address]] into another base. Since a compiler seldom knows where an object will reside, it often assumes a fixed base ___location (for example, [[zero base|zero]]). Relocating machine code may involve re-targeting of absolute jumps, loads, and stores.

The executable output by the linker may need another relocation pass when it is finally loaded into memory (just before execution). This pass is usually omitted on [[computer hardware|hardware]] offering [[virtual memory]]: every program is put into its own address space, so there is no conflict even if all programs load at the same base address. This pass may also be omitted if the executable is a [[position independent]] executable.

On some [[Unix]] variants, such as [[SINTRAN&nbsp;III]], the process performed by a linker (assembling object files into a program) was called ''[[loader (computing)|loading]]'' (as in loading executable code onto a file).<ref name="BRF_1984"/> Additionally, in some operating systems, the same program handles both the jobs of linking and loading a program ([[dynamic linking]]).

== Dynamic linking ==

Line 36 ⟶ 40:

There are also disadvantages:

* Known on the [[Windows]] platform as "[[DLL hell]]", an incompatible updated library will break executables that depended on the behavior of the previous version of the library if the newer version is incorrectly not correctly [[backward compatible]].

* A program, together with the libraries it uses, might be certified (e.g. as to correctness, documentation requirements, or performance) as a package, but not if components can be replaced (this also argues against automatic OS updates in critical systems; in both cases, the OS and libraries form part of a ''qualified'' environment).

[[Containerization (computing)|Contained]] or [[OS-level virtualization|virtual]] environments may further allow [[System administrator|system administrators]] to mitigate or trade-off these individual pros and cons.

Line 49 ⟶ 53:

== {{anchor|Consolidator}}Linkage editor ==

In IBM [[System/360]] through [[IBM Z]] [[Mainframe computer|mainframe]] environmentsoperating systems such as [[OS/360]], includingand [[z/successors|OS]]/360 forand theits [[z/Architecturesuccessors]] mainframes, this type of program is known as a ''linkage editor''. As the name implies a linkage ''editor'' has the additional capability of allowing the addition, replacement, and/or deletion of individual program sections. Operating systems such as OS/360 have format for executable load-modules containing supplementary data about the component sections of a program, so that an individual program section can be replaced, and other parts of the program updated so that relocatable addresses and other references can be corrected by the linkage editor, as part of the process.

One advantage of this is that it allows a program to be maintained without having to keep all of the intermediate object files, or without having to re-compile program sections that haven't changed. It also permits program updates to be distributed in the form of small files (originally [[card deck (computing)|card deck]]s), containing only the object module to be replaced. In such systems, object code is in the form and format of 80-byte punched-card images, so that updates can be introduced into a system using that medium. In later releases of OS/360 and in subsequent systems, load-modules contain additional data about versions of components modules, to create a traceable record of updates. It also allows one to add, change, or remove an [[overlay (programming)|overlay]] structure from an already linked load module.

The term "linkage editor" should not be construed as implying that the program operates in a user-interactive mode like a text editor. It is intended for batch-mode execution, with the editing commands being supplied by the user in sequentially organized files, such as [[punched card]]s, [[direct-access storage device|DASD]], or [[magnetic tape]], and tapes were often used during the initial installation of the OS.

''Linkage editing'' ([[IBM]] nomenclature) or ''consolidation'' or ''collection'' ([[International Computers Limited|ICL]] nomenclature) refers to the ''linkage editor's'' or ''consolidator's'' act of combining the various pieces into a relocatable binary, whereas the loading and relocation into an absolute binary at the target address is normally considered a separate step.<ref name="Barron_1978_Consolidator"/>

== CommonLinker implementationscontrol scripts ==

In the beginning linkers gave users very limited control over the arrangement of generated output object files. As the target systems became complex with different memory requirements such as embedded systems, it became necessary to give users control to generate output object files with their specific requirements such as defining base addresses' of segments. Linkers control scripts were used for this.

== Implementations ==

Notable implementations:

=== Unix & Unix-like ===

On Unix and Unix-like systems, the static linker is knownusually asinvoked "ld". Origins ofvia the namecommand "<code>ld"</code> arewhich is an abbreviation of "''LoaDer"'' andor "''Link eDitor"''. The term "loader" was used to describe the process of loading external symbols from other programs during the process of linking.<ref name="UNIX_V6_manuals"/>

For example, on [[SINTRAN&nbsp;III]], linking (assembling object files into a program) was called <!--do not link to [[loader (computing)]] since that's different-->''loading'' {{endash}} as in loading executable code onto a file.<ref name="BRF_1984"/>

On Unix and Unix-like systems, the linker is known as "ld". Origins of the name "ld" are "LoaDer" and "Link eDitor". The term "loader" was used to describe the process of loading external symbols from other programs during the process of linking.<ref name="UNIX_V6_manuals"/>

=== GNU linker ===

The GNU linkerld, (orpart of the [[GNU ldBinary Utilities]] (binutils), is the [[GNU Project]]'s [[free software]] implementationversion of the Unix command ld. GNU ld runs thestatic linker, which creates an executable file (or a library) from object files created during compilation of a software project. A ''linker script'' may be passed to GNU ld to exercise greaterfine grain control overof the linking process.<ref name="GNU_2018_Binutils"/> The GNU linker is part of the [[GNU Binary Utilities]] (binutils). Two versions of ld are provided in binutils: the traditional GNU ld based on [[Binary File Descriptor library|bfd]], and a "streamlined" ELF-only version called [[gold (linker)|gold]].

The command-line and linker script syntaxes of GNU ld is the ''de facto'' standard in much of the [[Unix-like]] world. The [[LLVM]] project's linker, ''{{vanchor|lld}}'', is designed to be drop-in compatible,<ref>{{cite web |title=LLD - The LLVM Linker — lld 14 documentation |url=https://lld.llvm.org/ |website=lld.llvm.org}}</ref> and may be used directly with the GNU compiler. Another drop-in replacement, mold, is a highly parallelized and faster alternative which is also supported by GNU tools.<ref>{{cite web |title=GCC 12 Adds Support For Using The Mold Linker |url=https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Mold-Linker |website=www.phoronix.com}}</ref>

==See also==

Line 70 ⟶ 82:

{{Div col|colwidth=20em}}

* [[Binary File Descriptor library]] (libbfd)

* [[Build (computing)]]

* [[Compile and go system]]

* [[DLL hell]]

Line 97 ⟶ 110:

<ref name="GNU_2018_Binutils">{{cite web |title=GNU Binutils: Linker Scripts |date=2018-07-18 |url=https://sourceware.org/binutils/docs/ld/Scripts.html |access-date=2019-01-18 |url-status=live |archive-url=https://web.archive.org/web/20200306230349/https://sourceware.org/binutils/docs/ld/Scripts.html |archive-date=2020-03-06}}</ref>

<ref name="UNIX_V6_manuals">{{cite book |title=UNIX PROGRAMMER'S MANUAL |date=May 1975 |edition=6 |chapter=1. ld }}</ref>

<ref name="Barron_1978_Consolidator">{{cite book |author-first=David William |author-last=Barron |author-link=David W. Barron |editor-first=J. John |editor-last=Floretin |title=Assemblers and Loaders |date=1978 |orig-year=1971, 1969 |edition=3 |publisher=[[Elsevier North-Holland Inc.]] |series=Computer Monographs |publication-place=New York, USAUS |___location=[[University of Southampton]], Southampton, UK |isbn=0-444-19462-2 |lccn=78-19961 |chapter=5.7. Linkage editors and consolidators |pages=65–66}} (xii+100 pages)</ref>

<ref name="Salomon_1992">{{cite book |author-first=David |author-last=Salomon |editor-first=Ian D. |editor-last=Chivers |title=Assemblers and Loaders |date=February 1993 |chapter=8.2.3 Automatic jump-sizing |pages=237–238 |orig-year=1992 |edition=1 |series=Ellis Horwood Series In Computers And Their Applications |publisher=[[Ellis Horwood Limited]] / [[Simon & Schuster International Group]] |___location=California State University, Northridge, California, USAUS |publication-place=Chicester, West Sussex, UK |isbn=0-13-052564-2 |chapter-url=http://www.davidsalomon.name/assem.advertis/asl.pdf |access-date=2008-10-01 |url-status=live |archive-url=https://web.archive.org/web/20200323010358/http://www.davidsalomon.name/assem.advertis/asl.pdf |archive-date=2020-03-23}} (xiv+294+4 pages)</ref>

}}

Line 105 ⟶ 118:

* {{cite book |publisher=[[International Business Machines Corporation]] |title=Operating System 360 - Linkage Editor (E) - Program Logic Manual |id=Program number 360S-ED-510. File No. S360-31. Form Y28-6610-2. |date=1969-07-23 |orig-year=June 1967 |edition=3 |url=http://www.bitsavers.org/pdf/ibm/360/Y28-6610_LinkEdit(E)_PLM.pdf |access-date=2020-03-07 |url-status=dead |archive-url=https://web.archive.org/web/20071001000734/http://www.bitsavers.org/pdf/ibm/360/Y28-6610_LinkEdit(E)_PLM.pdf |archive-date=2007-10-01}}

* {{cite journal |author-first=Douglas W. |author-last=Jones |author-link=Douglas W. Jones |title=Assembly Language as Object Code |journal=Software: Practice and Experience |volume=13 |issue=8 |date=August 1983 |publisher=[[John Wiley & Sons Ltd]] |issn=1097-024X |pages=715–725 |doi=10.1002/spe.4380130806 |s2cid=42995338 }}

* {{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, USAUS |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/] Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]

* {{cite journal |author-first1=Leon |author-last1=Presser |author-link1=Leon Presser |author-first2=John R. |author-last2=White |title=Linkers and Loaders |journal=[[ACM Computing Surveys]] |volume=4 |number=3 |___location=University of California, Santa Barbara, California, USAUS |date=September 1972 |pages=149–167 |doi=10.1145/356603.356605 |s2cid=5694671 |url=https://inst.eecs.berkeley.edu/~cs162/sp06/hand-outs/p149-presser-linker-loader.pdf |access-date=2020-03-07 |url-status=live |archive-url=https://web.archive.org/web/20200307001527/http://www-inst.eecs.berkeley.edu/~cs162/sp06/hand-outs/p149-presser-linker-loader.pdf |archive-date=2020-03-07}} (19 pages)

* {{cite journal |author-first=Norman |author-last=Ramsey |title=Relocating Machine Instructions by Currying |date=May 1996 |url=https://www.cs.tufts.edu/~nr/pubs/relocating.pdf |periodical=ACM SIGPLAN Notices |volume=31 |issue=5 |pages=226–236 |doi=10.1145/249069.231429 |archive-url=https://web.archive.org/web/20200518103430/https://www.cs.tufts.edu/~nr/pubs/relocating.pdf |archive-date=18 May 2020 |url-status=live}}

== External links ==

{{Wiktionary|linker}}

* [https://www.google.com/search?q=site%3Awww.airs.com%2Fblog%2Farchives+%22linkers+part%22 Ian Lance JustinTaylor's ''Linkers'' blog entries]

* [http://www.linuxjournal.com/article/6463 Linkers and Loaders], a [[Linux Journal]] article by Sandeep Grover

* [https://web.archive.org/web/20060808184333/http://www.dpgraph.com/assembly.html Another Listing of Where to Get a Complete Collection of Free Tools for Assembly Language Development]

* [https://sourceware.org/binutils/docs/ld/index.html GNU linker manual]

* [https://lld.llvm.org/ LLD - The LLVM Linker]

* {{man|1|ld|die.netLinux|The GNU linker}}

{{Application binary interface}}