Linker
Noun · Development
Definitions
Linker is a program that combines multiple compiled object files and libraries into a single executable or shared library. After a compiler translates source code into machine code contained in individual object files, the linker resolves references between them: when one module calls a function defined in another, the linker connects the call to the actual function address. Linking can be static (copying library code into the final executable at build time) or dynamic (referencing shared libraries that are loaded at runtime). Static linking produces larger but self-contained executables, while dynamic linking saves disk space and memory but requires the correct library versions to be present on the target system. Common linker errors include undefined reference (a symbol was declared but never defined) and multiple definition (the same symbol was defined in more than one object file). GNU ld, LLVM lld, and the Microsoft linker are widely used implementations.
In plain English: The program that glues together all the separately compiled pieces of your code into one runnable application.
Example: "undefined reference to main — the linker is telling you it can't find where your program starts."
Etymology
- 1947
- John Mauchly describes a 'linking loader' for combining subroutine libraries, one of the earliest references to linking.
- 1960s
- Linkers become standard tools as modular programming grows. They resolve symbols and combine object files into executables.
- 1990s
- Dynamic linking (shared libraries, DLLs) becomes common, reducing binary size and enabling runtime library updates.
- 2020s
- Modern linkers (lld, mold) focus on speed. Link-time optimization (LTO) blurs the line between compilation and linking.
Origin Story
The Glue That Assembles a Program from Pieces
A linker (also called a link editor) is a program that combines multiple compiled object files and libraries into a single executable program. The concept dates back to the early 1950s, when programs first grew too large to exist as a single compiled unit. As programming languages matured, the ability to compile code in separate modules became essential. Each module could be developed, tested, and compiled independently, but something needed to stitch them together into a working program, resolving references between modules (like function calls) and producing the final executable. The early UNIVAC and IBM systems had primitive linking capabilities built into their loaders. The term 'linkage editor' appeared in IBM documentation for the System/360 in the 1960s, and the concept was refined through the development of Unix at Bell Labs in the 1970s. The Unix linker 'ld' became a foundational tool. Static linking combines all needed code into one executable at build time. Dynamic linking, introduced widely in the 1980s, defers the resolution of some references to runtime, allowing shared libraries (like .dll files on Windows or .so files on Linux) to be loaded on demand. This saved disk space and memory, since many programs could share a single copy of a common library.
Context: Early computing, 1950s; formalized in IBM System/360 and Unix
Fun fact: The phrase 'DLL Hell,' describing conflicts between different versions of shared libraries on Windows, was so pervasive in the 1990s that Microsoft completely redesigned their deployment model with .NET and side-by-side assembly loading.