Editing Linker (computing) (section)

== 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 using [[symbol (computing)|symbols]] as addresses into other modules, which are mapped into memory addresses when linked for execution.

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,
* undefined "external" symbols, which reference other modules where these symbols are defined, and
* local symbols, used internally within the object file to facilitate [[relocation (computer science)|relocation]].

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 object files in a [[static library]] in the output executable; they include only those object files 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 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.

Additionally, in some operating systems, the same program handles both the jobs of linking and loading a program ([[dynamic linking]]).