Link-editing workflow in build systems: What is the primary output created by a linker when combining one or more object files and libraries?

Introduction / Context:
After compilation/assembly, object files contain code and data plus unresolved references. The linker’s job is to resolve references, perform relocation, and emit an image suitable for loading and execution. Understanding this step is essential to diagnosing build and runtime issues.

Given Data / Assumptions:

• Multiple object modules and libraries may be present.
• Some symbols are defined across different modules.
• A loader will later place the finished image into memory.

Concept / Approach:
The linker combines inputs to produce a load module (executable or shared library) with all external references resolved and sections relocated. The loader then maps this module into memory at run time. Compilers alone do not typically emit final, fully linked executables without invoking a linker stage (often invoked under the hood).

Step-by-Step Solution:

Verification / Alternative check:
Toolchains (e.g., ld, LINK) output .exe, .out, .elf, .dll, or .so—canonical load modules.

Why Other Options Are Wrong:
Not necessary with variable partitions: memory partitioning is unrelated to linking necessity. Must be run after the loader: inverted; the loader runs after linking. Not needed with a good compiler: compilers still rely on linking to combine modules.

Common Pitfalls:
Confusing compile and link steps; assuming a single-file program skips linking (the toolchain still links standard libraries).

Final Answer:
creates a load module