Linking fundamentals in systems programming: Object modules produced by an assembler may contain unresolved external references (symbols defined in other modules). Which program combines two or more such object files and resolves these externals to produce a single executable or library?

Introduction / Context:
When software is built, source code is translated into object modules that may reference functions or data defined elsewhere. Understanding which tool resolves these unresolved external references is central to build systems, portability, and modular program design.

Given Data / Assumptions:

• Multiple object modules exist after assembly/compilation.
• Some symbols are undefined in one module but defined in another.
• The goal is to create a runnable image or library with all references resolved.

Concept / Approach:
The linker reads object modules and libraries, matches undefined symbols to their definitions, performs relocation, lays out sections, and emits an executable or library. The loader places this finished image into memory at run time. The operating system provides system services, and the compiler/assembler generate object code but do not finish multi-module symbol resolution by themselves.

Step-by-Step Solution:

Verification / Alternative check:
Typical toolchains (e.g., gcc/clang + ld, MSVC + LINK) explicitly invoke a linker step that accepts multiple .o/.obj files and libraries to produce .exe, .out, or .dll/.so outputs.

Why Other Options Are Wrong:
Operating system: provides services; it does not resolve build-time externals. Loader: maps an already linked image into memory. Compiler: translates high-level code to objects but leaves unresolved references. None: incorrect because a linker exists for this function.

Common Pitfalls:
Confusing the loader with the linker; assuming the compiler alone creates executables; overlooking the relocation step performed at link time.

Final Answer:
linker