In system building, which tool is responsible for resolving externally defined symbols and producing a combined executable image?

Introduction / Context:
Modern software is typically split across multiple object files and libraries. Names (symbols) referenced in one module may be defined in another. The component that resolves these cross-module references at build time is the linker, which produces an executable or library with all external references satisfied.

Given Data / Assumptions:

• Object files contain symbol tables listing defined and undefined symbols.
• Libraries provide additional definitions for unresolved references.
• We are identifying the build-time tool that performs symbol resolution.

Concept / Approach:
The linker reads object modules, matches undefined symbols to definitions, performs relocation, and emits an executable image. In contrast, the loader maps an already-linked image into memory at run time. The compiler translates high-level code to intermediate/object code; the assembler converts assembly to object code. Only the linker resolves external symbols across modules.

Step-by-Step Solution:

Verification / Alternative check:
Build logs typically show the linker stage resolving symbols; unresolved external errors appear during linking, not during compiling or loading, confirming the linker’s role.

Why Other Options Are Wrong:

• Loader: Handles memory mapping and initialization at run time, not build-time symbol resolution.
• Compiler: Translates source to object; does not resolve externals across modules.
• Assembler: Converts assembly to object; external references remain for the linker.
• None of the above: Incorrect because the linker performs the resolution.

Common Pitfalls:
Confusing relocation (linker) with loading, or assuming the compiler “knows” other modules’ addresses during code generation—it does not in modular builds.

Final Answer:
Linker