Content deleted Content added
→Dynamic linking: notes about performance and containers/virtual environments |
→Overview: layman-language paragraph on why software is developed in separate units which are then linked together Tags: Reverted Visual edit |
||
Line 8:
== 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 of [[debug symbol|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,
Line 23 ⟶ 27:
On some [[Unix]] variants, such as [[SINTRAN 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 ==
| |||