[The World of Linkers—Theory 00] From a Function Call to a Running Program

When you write return add(1, 2);, a name and a declaration are enough to express what you want. The processor needs something more concrete: an address to jump to.

That address may not exist yet. The definition of add could be in a source file that has not been compiled, or in a library built months earlier. Somehow, independently produced pieces of machine code must become one working program.

This series follows that transformation: finding definitions, assigning addresses, repairing references, and following the resulting file into a process. Each tool relies on contracts established by the others. We will examine those contracts through source code, object files, linked bytes, and program behavior.

A call crosses a file boundary

Start with a program whose declarations agree. One file provides the function; another describes its interface and calls it.

1
// add.c
2
int add(int a, int b) { return a + b; }

1
// call_add.c
2
int add(int a, int b);
3

4
int main(void) {
5
    return add(1, 2);
6
}

Save both files in one directory on an x86-64 Linux machine with C development tools installed:

1
$ gcc call_add.c add.c -o app  # -o: name the output app
2
$ ./app
3
$ echo $?
4
3

There is no printed greeting. The 3 is the process's exit status, displayed by the immediately following echo $?. It is a small but useful observation: code compiled from one file has reached a function defined in another.

Here, GCC¹ acts as a compiler driver. It organizes the work needed for the inputs and options you supplied. That work has several distinct responsibilities, even when a particular toolchain combines them into fewer processes:

1. Preprocessing expands macros, incorporates included headers, and applies conditional compilation.
2. Compilation checks the resulting C translation unit, optimizes it, and selects instructions for the target processor.
3. Assembly encodes instructions and related directives into an object file.
4. Linking combines object files and libraries into the requested output.

An object file, usually named with an .o suffix, is already more than source code. It contains machine code and data. It must also describe unfinished work. While compiling call_add.c, the compiler knows how to pass two integers, but it does not know where add will end up. It leaves a reference that a later stage can resolve.

The linker finds the definition, places the code and data, and fills in the address-dependent parts. The driver also supplies startup files and libraries where needed: the operating system does not ordinarily enter a C program by calling main directly.

We can make the boundary visible by keeping the intermediate files:

1
$ gcc -c call_add.c -o call_add.o  # -c: stop after producing an object; do not link
2
$ gcc -c add.c -o add.o
3
$ gcc call_add.o add.o -o app
4
$ ./app
5
$ echo $?
6
3

The third command starts with object files, so it does not compile the C sources again. Change add.c, rebuild add.o, and relink; call_add.o can be reused. This is the practical value of separate compilation.

To inspect the driver's planned commands without executing them:

1
$ gcc -### call_add.c add.c -o app  # -###: display internal commands without running them

You may see cc1², as³, collect2⁴, and ld⁵. For now, associate them with source processing, assembly, and linking. Their names and the differences between GCC and Clang⁶ are explained in the appendix. A useful division of responsibilities does not imply that every toolchain launches the same collection of programs.

Separate compilation also creates an information boundary. Both files above agree on the type of add. What happens when two files use the same name but disagree about what it means?

One name, two incompatible views

Consider a variable defined as an integer in one file and declared as a floating-point object in another:

1
// main.c
2
#include <stdio.h>
3

4
int y = 5;
5
int x = 7;
6

7
void set_x(void);   /* defined in other.c */
8

9
int main(void) {
10
    set_x();
11
    printf("x = %d, y = %d\n", x, y);
12
    return 0;
13
}

1
// other.c
2
extern double x;
3

4
void set_x(void) {
5
    x = 1.0;
6
}

main.c allocates storage for two integers and calls set_x. The extern declaration in other.c does not allocate a second x; it says that storage will be provided elsewhere. But it describes that storage as a double.

When compiling other.c on its own, the compiler cannot see the definition in main.c. It generates a store appropriate for double. The question is whether the stage that combines the files will notice the disagreement.

A successful build, an invalid program

For this byte-level investigation, the recorded environment uses x86-64 Linux, GCC 15.2, and musl⁷ 1.2.5. The musl-gcc⁸ wrapper selects musl's headers, startup files, and libraries for the native compiler. Compilation, linking, and execution all happen on the same Linux machine.

The simple add example did not require musl. We introduce it here to keep the static executable and its runtime components consistent across the following inspections.

Create the working directory, then save the two files above as main.c and other.c there:

1
mkdir -p linker-example-ch00
2
cd linker-example-ch00

The incompatible declarations make this UB⁹. The output below is an observation of the displayed build, used to explain its machine code; C does not guarantee these values.

Compile separately and statically link the required library code into the executable:

1
$ musl-gcc -O2 -Wall -Wextra -c main.c -o main.o  # -O2: optimize; -Wall -Wextra: enable two groups of warnings
2
$ musl-gcc -O2 -Wall -Wextra -c other.c -o other.o
3
$ musl-gcc -static main.o other.o -o prog  # -static: include required library code in the executable
4
$ ./prog
5
x = 0, y = 1072693248

No compiler warning. No linker error. Yet y has changed, even though set_x never names it.

The incompatible declarations already make this program exhibit UB⁹. C requires declarations referring to the same object to have compatible types; see C11 draft N1570, §6.2.7 paragraph 2. The language does not promise the output above. We are explaining one recorded binary, not deriving a portable result from an invalid C program.

In this GCC build, -O2 puts the two globals in the reverse of their source order: x, then y. The assignment stores the eight-byte representation of 1.0, 0x3ff0000000000000, at x. On little-endian x86-64, the low four bytes land in x, producing zero; the high four bytes overwrite the adjacent y, producing 0x3ff00000, or 1072693248.

There is no floating-point-to-integer conversion here. Two pieces of machine code simply access the same address with different assumptions about its size.

Changing the build changes the observation. With -O0, with -fno-toplevel-reorder, or with Clang, the recorded native Linux experiments instead place y before x: they first print x = 0, y = 5, then terminate with SIGSEGV. An unchanged y does not make the oversized store valid. The compiler chooses the order inside this input data section; the linker carries that section into the output rather than individually reordering its variables.

Connecting a reference to a definition is symbol resolution. A symbol table describes names, positions, and attributes, but an ordinary native object file does not preserve the complete C type constraints needed to validate this assignment. Even a size field cannot prove that two declarations are compatible. Link-time optimization can retain richer compiler information and diagnose some cross-translation-unit mismatches; GCC's LTO documentation describes that different path.

The linker has produced a file the operating system is willing to start. What, exactly, did the operating system accept?

A file becomes a process

Besides instructions and data, an executable needs to say where its bytes belong, which memory may be written or executed, and where execution begins. The kernel uses those instructions to construct a process; it does not recheck the C program.

Linux's usual native toolchains use ELF¹⁰ for object files, executables, and shared objects. Inspect this executable's program headers with readelf¹¹; -l selects program headers and -W avoids wrapping long lines:

1
$ readelf -lW prog
2
Elf file type is EXEC (Executable file)
3
Entry point 0x40109e
4
There are 6 program headers, starting at offset 64
5

6
Program Headers:
7
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
8
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x000190 0x000190 R   0x1000
9
  LOAD           0x001000 0x0000000000401000 0x0000000000401000 0x004947 0x004947 R E 0x1000
10
  LOAD           0x006000 0x0000000000406000 0x0000000000406000 0x000cc8 0x000cc8 R   0x1000
11
  LOAD           0x006fc0 0x0000000000407fc0 0x0000000000407fc0 0x000150 0x0007f8 RW  0x1000
12
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
13
  GNU_RELRO      0x006fc0 0x0000000000407fc0 0x0000000000407fc0 0x000040 0x000040 R   0x1
14

15
 Section to Segment mapping:
16
  Segment Sections...
17
   00
18
   01     .init .text .fini
19
   02     .rodata .eh_frame
20
   03     .init_array .fini_array .data.rel.ro .got .got.plt .data .bss
21
   04
22
   05     .init_array .fini_array .data.rel.ro .got .got.plt

The program header table describes the file from the loader's point of view. A LOAD entry says, approximately:

Take FileSiz bytes starting at file offset Offset, map them at virtual address VirtAddr, and provide MemSiz bytes of memory with permissions Flg.

R, W, and E mean readable, writable, and executable. A virtual address is the address seen by the program; the operating system supplies the mapping to physical memory.

In this example, the first loadable region maps the initial 0x190 bytes at 0x400000, read-only. The next maps 0x4947 bytes at 0x401000, readable and executable. Read-only data follows. The final region begins at 0x407fc0: only 0x150 bytes come from the file, while its memory size is 0x7f8. The additional memory is zero-initialized.

The launch path reaches the kernel through execve. After validating the executable and establishing its mappings and initial stack—including arguments and environment—the kernel transfers control to the entry address, 0x40109e for this static executable. On x86-64, %rip holds the instruction pointer. This account follows the entry point and loadable regions; it is not an exhaustive list of the kernel's validation and setup work.

Other program headers carry different contracts. GNU_STACK declares stack permissions: RW requests a non-executable stack. GNU_RELRO describes a range that can become read-only after relocation. GNU_PROPERTY carries processor-related properties. Which component interprets a header, and with what effect, depends on the architecture, kernel, and runtime.

The lower half of the output connects two views of the same file:

• The linker organizes sections, such as .text for instructions, .data for initialized data, and .bss for zero-initialized storage.
• The loader maps segments, which can cover several sections at once.

Ordinary ELF loading follows program headers, not a loop that loads sections by their names. Our variables are in .data, covered by the fourth loadable segment.

These output addresses were not present in the same form at compile time. readelf -l main.o reports There are no program headers in this file. The linker supplies the executable's entry point, segment boundaries, permissions, and section addresses. x has section-relative value zero in main.o; in this prog, it has address 0x408008.

A valid loading plan and a correct C program are different claims. The kernel can honor the first without establishing the second.

Four stages, four places to fail

A useful debugging question is: which component had enough information to detect this problem?

For this discussion, compilation includes the path from a translation unit to an object file. Linking produces the executable. Loading establishes its startup environment. Execution runs its instructions. Runtime calls such as dlopen can trigger further loading and dynamic linking after startup, so these are responsibilities as well as moments in time.

Use a separate directory for the failure-stage examples, keeping the earlier type-mismatch sources and objects intact:

1
mkdir -p ../linker-example-phases
2
cd ../linker-example-phases

The following main.c and main.o belong to this new example. Return to a well-typed pair of files:

1
// add.c
2
int add(int a, int b) { return a + b; }

1
// main.c
2
int add(int a, int b);
3

4
int main(void) {
5
    return add(1, 2);
6
}

Compilation: the declaration contradicts the call

Change the call to add(1) and save it as bad.c:

1
$ musl-gcc -c bad.c
2
bad.c: In function 'main':
3
bad.c:5:12: error: too few arguments to function 'add'; expected 2, have 1
4
    5 |     return add(1);
5
      |            ^~~

This is an excerpt; the full diagnostic also points to the declaration. The compiler has the entire translation unit—the source file together with included headers—so it can compare the call against the visible function type. Its diagnostic names a source location precisely.

Linking: a name has no definition

Restore the correct call, compile it, but omit the object that defines add:

1
$ musl-gcc -c main.c
2
$ musl-gcc -static main.o -o app
3
ld: main.o: in function `main':
4
main.c:(.text+0x13): undefined reference to `add'
5
collect2: error: ld returned 1 exit status

The local linker executable's full pathname is shortened to ld in this excerpt. The linker reports the unresolved reference; collect2 then reports that the linker failed.

The declaration was sufficient to compile main.c. The object file contains a reference to add and a relocation identifying the address-dependent field. At link time, no supplied definition satisfies it. The .text+0x13 location identifies the relevant place inside the input section.

LLVM¹²'s LLD¹³ reports the same missing definition with different wording:

1
$ ld.lld -static main.o -o /dev/null
2
ld.lld: error: undefined symbol: add
3
>>> referenced by main.c
4
>>>               main.o:(main)

Collecting symbols from several object files does not reconstruct all their C declarations. An ordinary symbol table lets the linker look for a definition of add; it does not tell the linker how many C arguments this call should have supplied.

Loading: the library is no longer available

A dynamically linked executable can depend on code stored in a separate shared object. At startup, the dynamic linker locates and maps those dependencies and performs the required dynamic relocation. On this musl setup, the interpreter is /lib/ld-musl-x86_64.so.1; glibc¹⁴ systems commonly use an interpreter named ld-linux-x86-64.so.2.

Build a shared library and link against it:

1
$ musl-gcc -shared -fPIC add.c -o libadd.so
2
$ musl-gcc main.c -L. -ladd -o calc_dyn
3
$ readelf -lW calc_dyn | grep -A1 INTERP
4
  INTERP         0x000238 0x0000000000000238 0x0000000000000238 0x000019 0x000019 R   0x1
5
      [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]
6
$ readelf -dW calc_dyn | grep NEEDED
7
 0x0000000000000001 (NEEDED)             Shared library: [libadd.so]
8
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]

Here -shared requests a shared object, while -fPIC asks the compiler for position-independent code. -L. adds the current directory to the link-time library search; -ladd selects the library named add.

The link succeeds because libadd.so is present and exports the required definition. The executable's INTERP program header names the interpreter the kernel should start. Its NEEDED entries then tell that interpreter which shared libraries are required.

The current directory is not automatically a runtime library search directory:

1
$ ./calc_dyn
2
Error loading shared library libadd.so: No such file or directory (needed by ./calc_dyn)
3
Error relocating ./calc_dyn: add: symbol not found
4
$ echo $?
5
127

main has not started. In this case, status 127 comes from failure in the dynamic linker. Supply the runtime search directory for this invocation:

1
$ LD_LIBRARY_PATH=. ./calc_dyn
2
$ echo $?
3
3

Now the call executes and returns 3.

A library found during development may be absent—or installed elsewhere—on the deployment machine. Link-time success cannot establish the future runtime search path. Loader policies can introduce other failures too: glibc 2.41 changed how dlopen handles shared objects requesting an executable stack, as documented in its release notes. That release-specific example is background reading, not an experiment reproduced in this chapter.

Execution: the file is valid, the operation is not

Our mismatched x program passes compilation, linking, and loading. Its incorrect assumption becomes visible only when the generated store executes. The symptom may be a surprising number, a later crash, or a corrupted value that is rarely read.

The practical repair is to put extern int x in a shared header and include it in both the defining and using translation units. That gives each compilation the same contract and lets the compiler catch conflicting declarations where they are visible together.

Diagnostics often reveal their stage. Compiler errors usually identify source lines and columns. Linker errors identify symbols and input-file locations, sometimes also source locations recovered from metadata. Dynamic-linker errors name missing libraries or runtime symbols. Execution failures may produce no diagnostic at all.

Finally, distinguish a process's exit code from termination by a signal. Many shells display the latter as 128 + signal number, but a program can deliberately return the same numeric status. The number alone is not proof of how it terminated.

The linker has three connected jobs

Follow the assignment to x through the build and three responsibilities emerge:

1. Resolution: which definition does the reference mean?
2. Layout: where will that definition's bytes live in the output?
3. Relocation: what address or displacement must be written into the referring code or data?

1
 main.c --compile--> main.o  --+
2
                               +--> linker --> prog --> loader --> process
3
other.c --compile--> other.o --+             (executable)

A wrong definition, wrong permission, and wrong displacement produce different failures. Even a correct implementation of all three jobs can carry a source-level type error into the process. To judge a linker, we must examine both its interpretation of the input contracts and the behavior of its output.

Separate compilation remains valuable: it allows incremental builds and independently distributed libraries. Its price is an explicit description of what every object provides, what it needs, and which locations still need adjustment. An object file cannot be only a stream of instructions, and linking cannot be simple file concatenation.

Before object formats and symbol tables existed, moving reusable code meant repairing addresses by hand. That concrete problem is where the next chapter begins.

Set up the native Linux environment

The main ELF experiments target x86-64 Linux. Use an x86-64 Linux host or virtual machine and run the following commands there. Connecting from another computer over SSH does not change the experiment's location: compile and execute on the Linux host.

1
uname -sm

Expect Linux and x86_64. Under cross-architecture emulation, uname may describe the emulated environment, so also establish how the host and container or VM actually run.

On Debian or Ubuntu, install the native tools and build a small smoke test:

1
sudo apt-get update
2
sudo apt-get install build-essential binutils file gdb coreutils musl-tools clang llvm lld \
3
  python3 git strace
4
gcc -dumpmachine
5
gcc --version
6
ld --version
7
mkdir -p "$HOME/linker-lab"
8
cd "$HOME/linker-lab"
9
printf 'int main(void) { return 42; }\n' > hello42.c
10
musl-gcc -static hello42.c -o hello42
11
file hello42
12
readelf -h hello42
13
./hello42
14
echo $?

The gcc -dumpmachine target should include x86_64 and linux; the final status should be 42. build-essential supplies the usual C/C++ development tools, and binutils¹⁵ supplies tools such as ld, readelf, objdump¹⁶, and nm¹⁷. Debian's musl-tools package provides a wrapper for the native architecture; it does not by itself turn an ARM host compiler into an x86-64 cross-compiler.

The recorded baseline is Ubuntu 26.04, GCC 15.2, GNU¹⁸ binutils 2.46, and Clang/LLD 21.1.8. We use musl-gcc for the musl C experiments and gcc/g++ for system-glibc and C++ experiments. Switching the C library also changes startup files and, for dynamic executables, the interpreter. Do not mix their outputs when comparing addresses or diagnostics.

Exercises

For Observe, use the type-mismatch example's prog, main.o, and other.o in linker-example-ch00, not the later addition example's main.o. Use independent directories for Predict and each case A–F. For Break it, then repair it, work on a copy of the type-mismatch sources. The same filenames denote different inputs in these examples.

Observe

1. Find the entry address with readelf -h prog or readelf -l prog. Use nm prog to identify the symbol there. Is it main?
2. The fourth LOAD has file size 0x150 and memory size 0x7f8. Use the section-to-segment mapping and readelf -SW prog to account for the difference.
3. Compare nm main.o with nm other.o. How is x represented in each? Inspect its type and size with readelf -s other.o. Can those fields tell you that other.c assumed double?

Predict

Will these files link? If they do, will they print a value or crash? Write down a prediction before trying them.

1
// table.c
2
int table[2] = {1, 2};

1
// use.c
2
#include <stdio.h>
3

4
extern int *table;
5

6
int main(void) {
7
    printf("table[1] = %d\n", table[1]);
8
    return 0;
9
}

Locate the failure

For each case, predict whether the problem is detected during compilation, linking, loading, or execution. Unless stated otherwise, build the listed files together with musl-gcc -static.

A. A misspelled function call in one file:

1
#include <stdio.h>
2
int square(int n) { return n * n; }
3
int main(void) { printf("%d\n", squre(3)); return 0; }

B. Two translation units each contain a tentative definition:

1
// a.c
2
int count;
3
void bump(void) { count++; }

1
// main.c
2
#include <stdio.h>
3
int count;
4
void bump(void);
5
int main(void) { bump(); printf("%d\n", count); return 0; }

C. A caller tries to reach another file's internal helper:

1
// util.c
2
static int helper(int n) { return n + 1; }
3
int twice(int n) { return helper(n) * 2; }

1
// main.c
2
int helper(int n);
3
int main(void) { return helper(41); }

D. Both files include a header, but the definition disagrees with it:

1
// scale.h
2
int scale(int v);

1
// scale.c
2
#include "scale.h"
3
long scale(long v) { return v * 10; }

1
// main.c
2
#include "scale.h"
3
int main(void) { return scale(4); }

E. Build a shared library and run the executable without setting LD_LIBRARY_PATH:

1
// greet.c
2
#include <stdio.h>
3
void greet(void) { puts("hello from libgreet"); }

1
// main.c
2
void greet(void);
3
int main(void) { greet(); return 0; }

1
$ musl-gcc -shared -fPIC greet.c -o libgreet.so
2
$ musl-gcc main.c -L. -lgreet -o prog

F. Compile these files with -Wall -Wextra:

1
// limit.c
2
long long limit = 5000000000LL;

1
// main.c
2
#include <stdio.h>
3
extern int limit;
4
int main(void) { printf("limit = %d\n", limit); return 0; }

Break it, then repair it

In the earlier other.c, replace extern double x; with double x = 1.0; and leave set_x empty. Keep main.c unchanged. Predict the failure stage, then inspect the diagnostics from GNU ld and LLD. Compare the size fields for x in both objects using readelf -s.

Finally, repair other.c with extern int x; and assign x = 1;. Confirm that y remains 5.

A test harness should represent normal exits and signal termination separately. The process harness records each command's return code. Python's subprocess represents signal termination as a negative signal number, distinguishing it from a normal exit.

Worked answers

The outputs below come from native Linux runs in isolated temporary directories. The example contains the source files, commands, and failing cases, and retains each run's artifacts.

1
$ readelf -hW prog | grep Entry
2
  Entry point address:               0x40109e
3
$ nm prog | grep -E " _start$| _start_c$| main$"
4
000000000040109e T _start
5
00000000004010c0 T _start_c
6
0000000000401070 T main

1
$ readelf -lW prog | grep -E "^   03"
2
   03     .init_array .fini_array .data.rel.ro .got .got.plt .data .bss
3
$ readelf -SW prog | grep -E "init_array|fini_array|data|bss"
4
  [ 4] .rodata           PROGBITS        0000000000406000 006000 000c7a 00   A  0   0 32
5
  [ 6] .init_array       INIT_ARRAY      0000000000407fc0 006fc0 000008 08  WA  0   0  8
6
  [ 7] .fini_array       FINI_ARRAY      0000000000407fc8 006fc8 000008 08  WA  0   0  8
7
  [ 8] .data.rel.ro      PROGBITS        0000000000407fd0 006fd0 000010 00  WA  0   0  8
8
  [11] .data             PROGBITS        0000000000408000 007000 000110 00  WA  0   0 32
9
  [12] .bss              NOBITS          0000000000408120 007110 000698 00  WA  0   0 32

1
$ nm main.o
2
0000000000000000 T main
3
                 U printf
4
                 U set_x
5
0000000000000000 D x
6
0000000000000004 D y
7
$ nm other.o
8
0000000000000000 r .LC0
9
0000000000000000 T set_x
10
                 U x
11
$ readelf -sW other.o | grep -E " x$"
12
     5: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND x

1
$ musl-gcc -O2 -Wall -Wextra -static table.c use.c -o arr
2
$ ./arr
3
$ echo $?
4
139

1
$ objdump -dr --no-show-raw-insn use.o
2
   8:	mov    0x0(%rip),%rax        # f <main+0xf>
3
			b: R_X86_64_PC32	table-0x4
4
  ...
5
  16:	mov    0x4(%rax),%esi

1
$ musl-gcc -static main.c -o prog
2
main.c: In function 'main':
3
main.c:3:33: error: implicit declaration of function 'squre'; did you mean 'square'? [-Wimplicit-function-declaration]

1
$ musl-gcc -c a.c && musl-gcc -c main.c
2
$ musl-gcc -static a.o main.o -o prog
3
ld: main.o:(.bss+0x0): multiple definition of `count'; a.o:(.bss+0x0): first defined here
4
collect2: error: ld returned 1 exit status

1
$ musl-gcc -c util.c && musl-gcc -c main.c
2
$ musl-gcc -static util.o main.o -o prog
3
ld: main.o: in function `main':
4
main.c:(.text+0xe): undefined reference to `helper'
5
collect2: error: ld returned 1 exit status
6
$ nm util.o
7
0000000000000000 t helper
8
0000000000000013 T twice

1
scale.c:3:6: error: conflicting types for 'scale'; have 'long int(long int)'
2
    3 | long scale(long v) { return v * 10; }
3
      |      ^~~~~
4
In file included from scale.c:2:
5
scale.h:2:5: note: previous declaration of 'scale' with type 'int(int)'

1
$ ./prog
2
Error loading shared library libgreet.so: No such file or directory (needed by ./prog)
3
Error relocating ./prog: greet: symbol not found
4
$ echo $?
5
127

1
$ ./prog
2
limit = 705032704

1
$ musl-gcc -O2 -Wall -Wextra -c main.c && musl-gcc -O2 -Wall -Wextra -c other.c
2
$ musl-gcc -static main.o other.o -o prog
3
ld: other.o:(.data+0x0): multiple definition of `x'; main.o:(.data+0x0): first defined here
4
collect2: error: ld returned 1 exit status
5
$ ld.lld -static main.o other.o -o /dev/null
6
ld.lld: error: duplicate symbol: x
7
>>> defined at main.c
8
>>>            main.o:(x)
9
>>> defined at other.c
10
>>>            other.o:(.data+0x0)
11
$ readelf -sW main.o | grep -E " x$"
12
     7: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    2 x
13
$ readelf -sW other.o | grep -E " x$"
14
     4: 0000000000000000     8 OBJECT  GLOBAL DEFAULT    2 x

1
$ cat other.c
2
extern int x;
3

4
void set_x(void) {
5
    x = 1;
6
}
7
$ musl-gcc -O2 -Wall -Wextra -c other.c
8
$ musl-gcc -static main.o other.o -o prog
9
$ ./prog
10
x = 1, y = 5

References

• The incompatible-object example is adapted from CMU 15-213's Linking lecture, “Linker Puzzles,” page 22. This version uses extern double x to avoid a modern -fno-common duplicate-definition error and changes source order to expose the recorded GCC layout. Its output is an observation of that binary, not a C guarantee.
• C11 draft N1570, §6.2.7 and GCC's -flto documentation describe different levels of type information and checking.
• MIT 6.035, Computer Language Engineering, and MIT 6.828 JOS Lab 1 provide complementary compiler and loading perspectives.
• Format and architecture contracts: ELF gABI and x86-64 psABI.
• Toolchain changes: GCC 10, GCC 14, and glibc 2.41 NEWS.
• musl libc.