【C 语言】编译和链接：从源文件、目标文件到可执行程序完整解析

🔥 星光编译者 · 个人主页

📚 学习专栏： 《C/C++ 成长笔记》 · 《Linux 实践手册》 · 《数据结构与算法》

🌄 向云端飞扬，编译属于自己的代码星河。

☕ 写在开篇

你好，这里是 星光编译者。

这里记录我在 C/C++、Linux、数据结构与算法 学习中遇到的真实问题、亲手验证过的代码，以及那些容易被忽略的实现细节。

比起简单罗列结论，我更愿意从问题出发，把一个知识点的来由讲清楚，把"为什么会这样"和"应该怎样解决"说明白，让每一次踩坑都沉淀成可以复用的经验。

如果这篇记录能帮你少绕一点路，或让某个模糊的地方忽然变得清晰，那么这次分享便有了意义。愿我们在一次次阅读、编译与调试中稳步向前，慢慢搭起属于自己的技术世界。

🔥 本文定位：沿着一条 C 程序的真实构建链路，讲清翻译环境、运行环境、预处理、编译、汇编、目标文件、符号决议、重定位以及程序装载。

💡 学习目标 ：能够解释 .c → .i → .s → .o → 可执行文件 每一步做了什么；能够独立构建多文件项目；能够区分预处理错误、编译错误、链接错误和运行错误。

📌 环境约定 ：命令示例以 GCC 风格工具链为主。在 Windows + MSVC 中，目标文件常为 .obj，链接产物常为 .exe；在 Linux/Unix 中，目标文件通常为 .o，可执行文件常采用 ELF 格式。具体文件格式、指令和地址由平台、ABI 与编译器决定。

文章目录

一、先分清两个世界：翻译环境与运行环境
[二、总览：一条 C 程序怎样变成可执行文件](#二、总览：一条 C 程序怎样变成可执行文件)
三、预处理：处理所有以井号开头的指令
四、编译：从记号、语法树到汇编代码
五、汇编：从助记符到可重定位目标文件
六、多文件项目为什么可以分别编译
七、链接：符号决议、地址布局与重定位
八、亲手走一遍多文件构建流程
九、四类错误应该怎样定位
十、可执行文件生成以后发生了什么
十一、常用命令、高频问答与练习
总结

一、先分清两个世界：翻译环境与运行环境

写下 printf("hello\n"); 时，我们看到的是变量、函数与语句；处理器最终执行的却是机器指令。源代码不能直接跨过这道鸿沟，中间必须经历一套翻译过程。

ANSI C 的经典描述把整个过程划分为两个环境：

翻译环境：把源代码转换成能够执行的程序映像；
运行环境：装载并执行已经生成的程序。

这两个环境解决的问题不同。翻译环境关心"代码怎样变成机器可以处理的形式"，运行环境关心"这个程序怎样进入内存、获得运行条件并最终结束"。

因此，下面三句话不能画等号：

编译通过：某个翻译阶段接受了代码；
链接通过：程序所需的符号和模块能够组成一个产物；
运行正确：程序在给定输入与环境下得到预期结果。

一段越界访问代码完全可能顺利生成可执行文件，然后在运行时崩溃；一段调用了不存在函数的代码，也可能先生成目标文件，直到链接时才失败。

第一条排错原则：先确认问题发生在哪个阶段，再检查该阶段的输入。不要把所有构建失败都笼统地叫作"编译错误"。

二、总览：一条 C 程序怎样变成可执行文件

课程把翻译过程概括为两个大阶段：编译与链接。如果继续展开编译部分，可以得到更便于观察的四阶段模型：

text 复制代码

源文件            预处理             编译              汇编             链接
test.c   ───→     test.i   ───→      test.s   ───→     test.o   ───→   app
          gcc -E             gcc -S             gcc -c          gcc ... -o

对应命令如下：

bash 复制代码

# 1. 只做预处理：.c -> .i
gcc -E test.c -o test.i

# 2. 把预处理结果编译成汇编：.i -> .s
gcc -S test.i -o test.s

# 3. 把汇编代码变成目标文件：.s -> .o
gcc -c test.s -o test.o

# 4. 链接目标文件：.o + 库 -> 可执行文件
gcc test.o -o app

开发时很少手动保存所有中间文件，通常会直接写：

bash 复制代码

gcc test.c -o app

这并不表示中间阶段消失了，只是 GCC 驱动程序替我们连续调用了相应工具，并把临时产物隐藏起来。

同理：

bash 复制代码

gcc -c test.c -o test.o

并不是"只做了一次简单编译"，而是让工具链完成预处理、编译和汇编，然后在目标文件处停下，不执行最终链接。

2.1 常见后缀分别表示什么

后缀或产物	常见含义	是否可以直接运行
`.c`	C 源文件	否
`.h`	供多个源文件包含的声明接口	否
`.i`	已预处理的 C 源文件	否
`.s`	汇编代码	否
`.o` / `.obj`	可重定位目标文件	通常不能
ELF / `.exe`	已链接的可执行程序	在匹配平台上可以

目标文件已经包含机器码，但通常仍有地址没有最终确定，也可能仍引用其他模块和库中的符号，所以它还不是一个完整程序。

三、预处理：处理所有以井号开头的指令

预处理器主要处理 #include、#define、#if、#ifdef、#pragma 等预处理指令。它工作在真正的语法与类型检查之前。

3.1 宏展开

例如：

c 复制代码

#define SCALE 8

int result = value * SCALE;

预处理后，使用处会形成类似下面的结果：

c 复制代码

int result = value * 8;

宏本质上是预处理记号层面的替换机制，不是函数调用，也没有普通 C 表达式那样的类型系统。带参数宏尤其要注意括号与副作用：

c 复制代码

#define SQUARE(x) ((x) * (x))

即便写了完整括号，SQUARE(i++) 仍会多次求值，所以不能只把宏当作"更快的函数"。

3.2 条件编译

c 复制代码

#ifdef DEBUG
    printf("value = %d\n", value);
#endif

如果没有定义 DEBUG，这段调试代码在后续编译阶段根本不会出现。排查"为什么某段代码没有参与构建"时，查看 .i 文件往往比盯着原始 .c 文件更直接。

可以在命令行定义宏：

bash 复制代码

gcc -DDEBUG -E test.c -o test.i

3.3 头文件包含

c 复制代码

#include "add.h"

可以理解为：预处理器在此处展开被包含头文件的内容，而且头文件内部还可以继续包含其他头文件。这也是头文件需要包含保护的原因：

c 复制代码

#ifndef ADD_H
#define ADD_H

int Add(int x, int y);

#endif

也可以使用编译器普遍支持的 #pragma once，但标准 C 中最传统、最清晰的可移植写法仍是宏包含保护。

3.4 注释、行号与编译器指令

在普通预处理流程中，注释会被空白取代；预处理结果还可能带有文件名与行号标记，帮助后续编译器产生诊断和调试信息。#pragma 等实现相关指令则可能被保留，交给后续阶段处理。

当遇到下面这些问题时，可以优先检查预处理结果：

宏到底展开成了什么；
条件编译选择了哪个分支；
某个头文件是否真的被包含；
包含顺序是否引入了意外定义；
错误位置为何指向另一个文件或奇怪行号。

预处理能把声明带进当前翻译单元，但它无法证明声明对应的函数实现一定存在。实现能否找到，是链接阶段的问题。

四、编译：从记号、语法树到汇编代码

狭义的"编译"接收预处理结果，完成词法分析、语法分析、语义分析、优化与代码生成，最后得到汇编代码。

假设有下面的表达式：

c 复制代码

array[index] = (index + 4) * (2 + 6);

4.1 词法分析：把字符切成记号

扫描器读取字符流，并识别出不同类别的记号，例如：

text 复制代码

标识符  array
符号    [
标识符  index
符号    ]
运算符  =
符号    (
标识符  index
运算符  +
整数    4
...

此时编译器已经不再把源码看作一长串字符，而是看作关键字、标识符、字面量、运算符与分隔符组成的记号流。

常见的非法字符、无法形成合法记号的数字写法等问题，会在这一层暴露。

4.2 语法分析：构造表达式结构

语法分析器按照 C 语言文法把记号组织成树。运算符优先级、结合性和括号在这一步形成明确结构。

上面的表达式不是从左到右机械计算，而是具有清楚的层次：

array[index] 是赋值左侧；
(index + 4) 和 (2 + 6) 分别形成加法子树；
两个加法结果相乘；
最后把结果写入数组元素。

缺少右括号、少写分号、把关键字放在不合法位置等错误，通常会在语法分析阶段报告。

4.3 语义分析：语法正确还不够

下面的语句从标点和结构上可能像一个合法表达式，但类型未必允许：

c 复制代码

int *p = 0;
double d = p + 3.14;  /* 类型与运算语义不成立 */

语义分析会检查：

标识符是否已经声明；
操作数类型是否支持对应运算；
赋值两侧是否兼容；
函数参数数量和类型是否匹配；
必要的隐式转换怎样进行；
表达式是否满足左值等上下文要求。

编译器进行的是静态语义分析。它能发现许多在不运行程序时就可确定的问题，却不能保证业务逻辑正确，也通常不能证明所有数组下标在运行时都合法。

4.4 优化与代码生成

对常量表达式：

c 复制代码

(2 + 6)

编译器可能在构建过程中直接折叠为 8，无需让处理器在运行时再次计算。启用优化后，还可能进行公共子表达式消除、死代码删除、循环优化、函数内联等变换。

随后，编译器把中间表示映射为目标体系结构的指令，输出 .s 汇编文件：

bash 复制代码

gcc -S test.i -o test.s

不同编译器、不同版本、不同优化级别以及不同处理器架构，生成的汇编都可能不同。汇编结果应被看作"这个工具链在这些选项下的实现结果"，而不是 C 语言语义本身。

五、汇编：从助记符到可重定位目标文件

汇编器读取 .s 文件，根据目标指令集把汇编助记符编码成机器指令，并生成 .o 或 .obj 目标文件。

bash 复制代码

gcc -c test.s -o test.o

目标文件通常不只有一串机器码，还会包含若干节和元数据。以常见 ELF 思路为例，可以看到：

.text：机器指令；
.rodata：只读常量；
.data：已初始化的全局或静态数据；
.bss：零初始化或未显式初始化的静态存储期对象所需空间描述；
符号表：本文件定义或引用了哪些符号；
重定位记录：哪些位置还需要链接器修正；
调试信息：在启用 -g 等选项时记录源码与机器指令之间的关系。

"汇编器把一条汇编指令变成一条机器指令"适合作为入门直觉，但不要把它理解成绝对的一一对应。伪指令、数据定义、对齐指令以及某些架构上的展开，都可能让源级汇编行与最终字节不严格一一对应。

通常，大部分高级优化发生在生成汇编以前；汇编器主要负责解析汇编语法、编码指令、组织节并留下必要的符号与重定位信息。

5.1 为什么目标文件仍不能直接执行

假设 test.c 调用了另一个文件中的 Add：

c 复制代码

int sum = Add(a, b);

独立编译 test.c 时，编译器只知道 Add 的声明，不知道它最终被放到可执行文件的哪个地址。于是目标文件会记录：

text 复制代码

这里需要调用符号 Add
这个位置等链接器确定地址后再修正

这类"以后再填"的位置，就是重定位记录存在的重要原因。

六、多文件项目为什么可以分别编译

一个项目经常包含多个 .c 文件：

text 复制代码

test.c
add.c
log.c
config.c
...

每个 .c 文件经过预处理后，会与展开进来的头文件内容共同形成一个翻译单元。不同翻译单元可以独立编译成目标文件，最后再链接。

这种设计带来两个直接好处：

修改一个实现文件时，通常不必重新编译所有无关源文件；
接口与实现可以分离，模块边界更加清楚。

6.1 头文件应该放声明

add.h：

c 复制代码

#ifndef ADD_H
#define ADD_H

extern int g_val;
int Add(int x, int y);

#endif

这里的函数声明告诉使用者：存在一个名为 Add 的函数，它接收两个 int 并返回 int。

extern int g_val; 声明 g_val 在其他位置定义。它通常不为对象分配存储，也不会创建一个"备用变量"。

6.2 一个外部对象通常只定义一次

add.c：

c 复制代码

#include "add.h"

int g_val = 2022;

int Add(int x, int y)
{
    return x + y;
}

test.c：

c 复制代码

#include <stdio.h>
#include "add.h"

int main(void)
{
    int a = 10;
    int b = 20;
    int sum = Add(a, b);

    printf("sum = %d, g_val = %d\n", sum, g_val);
    return 0;
}

把对象定义直接写进普通头文件，可能导致每个包含它的翻译单元都产生一份定义，最终出现重复定义。稳定规则是：

声明放头文件，外部定义放某一个 .c 文件；使用者包含头文件，而不是手写一份可能漂移的声明。

6.3 `static` 会改变跨文件可见性

文件作用域下：

c 复制代码

static int helper_value = 10;
static int Helper(void) { return helper_value; }

这些名字具有内部链接，只在当前翻译单元中参与名称绑定。其他 .c 文件即使写下同名声明，也不能借此访问这里的实体。

这正适合隐藏模块私有实现，减少全局符号冲突。

七、链接：符号决议、地址布局与重定位

链接器把多个目标文件与所需库组合起来，生成最终程序。入门阶段最重要的三个关键词是：

符号决议：每个外部引用到底对应哪个定义；
地址与空间布局：代码和数据放到最终映像的什么位置；
重定位：根据最终布局修正指令或数据中的地址相关位置。

7.1 符号是什么

可以先把符号理解为链接器认识的名字，例如：

text 复制代码

Add
g_val
main
printf

test.o 对 Add 和 g_val 是引用方，add.o 是定义方。链接器必须找到兼容的定义，才能完成程序。

如果找不到定义，GCC/Clang 工具链常见报错类似：

text 复制代码

undefined reference to `Add'

MSVC 常见：

text 复制代码

unresolved external symbol Add

如果出现多个不允许共存的外部定义，则可能看到：

text 复制代码

multiple definition of `g_val'

或者 MSVC 的 LNK2005。

7.2 重定位到底在"修"什么

独立编译时，test.o 不能预知 Add 最终地址。它会在调用位置保留占位内容，并记录一种类似下面的请求：

text 复制代码

当 Add 的地址确定后，请修正这里的调用目标

链接器布局所有输入节、决定符号地址后，再按照重定位记录写回正确值。全局变量 g_val 的访问同理。

需要注意：现代系统经常使用位置无关代码、动态链接、PLT/GOT、地址随机化等机制，因此"把绝对地址直接写进每条指令"不是所有平台的真实做法。入门时抓住不变的核心即可：

目标文件中的某些地址相关内容尚未最终确定，链接器根据符号和布局完成修正或建立运行时解析机制。

7.3 库也参与链接

库是预先组织好的目标代码集合。常见形式包括：

静态库：Linux/Unix 常见 .a，Windows 常见 .lib；
共享库：Linux 常见 .so，Windows 常见 .dll，macOS 常见 .dylib。

静态链接通常把需要的目标代码纳入最终产物；动态链接通常在可执行文件中记录对共享库和符号的依赖，由系统装载器在装载期或运行中协助解析。

为什么链接时推荐使用 gcc 而不是初学阶段直接调用 ld？因为 gcc 驱动程序会替 C 程序加入合适的启动文件、运行库和默认选项。直接调用底层链接器需要自己处理更多平台细节。

7.4 声明与定义必须一致

链接器主要按目标文件中的符号与 ABI 约定工作，无法替你恢复全部源级意图。错误声明可能让不同翻译单元对同一个函数形成不一致认识，结果可能是警告、链接失败，也可能是更隐蔽的未定义行为。

所以不要在多个 .c 文件里重复手写接口：

c 复制代码

/* 容易与真实定义漂移 */
int Add(int, int);

应该让声明和定义共同包含同一个头文件，使编译器尽早发现不一致。

八、亲手走一遍多文件构建流程

以前面的 test.c、add.c、add.h 为例，先分别编译：

bash 复制代码

gcc -std=c11 -Wall -Wextra -c test.c -o test.o
gcc -std=c11 -Wall -Wextra -c add.c  -o add.o

此时目录中会出现两个目标文件：

text 复制代码

test.o
add.o

再进行链接：

bash 复制代码

gcc test.o add.o -o app

运行：

bash 复制代码

./app

预期输出：

text 复制代码

sum = 30, g_val = 2022

也可以一步完成：

bash 复制代码

gcc -std=c11 -Wall -Wextra test.c add.c -o app

8.1 故意制造一个链接错误

如果链接时漏掉 add.o：

bash 复制代码

gcc test.o -o app

test.o 已经成功生成，所以 test.c 的语法和静态语义检查可以通过；但链接器找不到 Add 与 g_val 的定义，最终失败。

这很好地说明：

text 复制代码

有声明 → 编译器可以检查调用形式
有定义 → 链接器才能完成符号绑定

8.2 查看目标文件中的符号

在提供相应 binutils 的 Unix-like 环境中，可以使用：

bash 复制代码

nm test.o
nm add.o

你通常会看到 test.o 中的 Add、g_val 处于未定义引用状态，而 add.o 提供定义。还可以查看重定位项：

bash 复制代码

objdump -r test.o

不同平台工具名称和输出格式会变化，但观察思路相同：谁引用符号、谁定义符号、哪些位置等待重定位。

8.3 为什么修改头文件可能触发大量重编译

因为头文件内容会被预处理进每个包含它的翻译单元。修改 add.h 后，所有直接或间接依赖它的 .c 文件，其预处理结果都可能改变，因此构建系统需要重新编译这些目标文件。

这也是大型项目重视依赖追踪、增量构建和接口稳定性的原因。

九、四类错误应该怎样定位

9.1 预处理错误

典型表现：

text 复制代码

fatal error: add.h: No such file or directory

优先检查：

头文件路径和 -I 选项；
包含名大小写；
条件编译是否屏蔽了需要的声明；
宏展开是否改变了原本代码；
是否发生递归包含或包含顺序问题。

最有价值的中间产物是 .i 文件。

9.2 编译错误

典型表现：

expected ';'；
undeclared identifier；
incompatible types；
函数参数数量不匹配；
把不能调用的对象当成函数。

优先检查源码在预处理后的真实形态、诊断指出的第一处错误以及相关类型声明。后续大量报错可能只是第一处语法错误引发的连锁反应。

9.3 链接错误

典型表现：

undefined reference / unresolved external symbol；
multiple definition / LNK2005；
找不到库文件；
目标架构或 ABI 不兼容；
在部分工具链中，静态库顺序不正确。

优先检查：

对应实现文件是否参与构建；
符号是否真的有且只有一个合适定义；
声明与定义是否一致；
static 是否让符号仅在当前文件可见；
库路径、库名称、位数和链接顺序是否正确。

9.4 运行错误

链接成功后仍可能出现：

空指针解引用；
数组越界；
除零；
栈溢出；
使用已释放内存；
动态库缺失；
输入、权限、工作目录或环境变量不符合预期；
逻辑正确性问题。

这些问题不应再回头笼统归咎于"编译器"。应使用调试器、日志、断言、AddressSanitizer/UndefinedBehaviorSanitizer 等工具继续定位。

例如 GCC/Clang 常见调试构建：

bash 复制代码

gcc -std=c11 -Wall -Wextra -g \
    -fsanitize=address,undefined \
    test.c add.c -o app

开启警告很重要，但"零警告"也不等于"零错误"。编译器只检查它能静态推断出的那部分事实。

十、可执行文件生成以后发生了什么

链接完成并不代表整个程序生命周期结束，恰恰相反，运行环境的工作刚刚开始。

课程给出的运行环境可以整理成四步：

程序被装入内存；
执行开始并最终进入 main；
用户代码使用栈、静态存储区和其他运行时资源；
程序正常或异常终止。

在现代操作系统中，更准确的理解是：

10.1 装载程序映像

操作系统内核与装载器根据可执行文件格式建立进程地址空间，映射代码与数据，准备所需共享库，并设置程序启动需要的状态。

10.2 运行库先于 `main` 工作

处理器通常不是从 main 的第一行直接开始。入口点先进入 C 运行库的启动代码，准备命令行参数、环境信息和运行时设施，然后调用 main。

因此，下面的流程更接近现实：

text 复制代码

操作系统装载 → 运行库入口 → 初始化 → main → 退出处理 → 返回系统

10.3 程序使用不同存储期的对象

自动存储期对象通常随块进入和离开而创建、结束生命周期，常见实现会使用运行时栈；
静态存储期对象贯穿程序整个执行过程；
动态分配对象由 malloc 等接口取得，必须根据所有权规则适时 free；
函数调用还需要保存返回信息、寄存器状态等运行上下文。

"局部变量一定全部在物理栈上"也不是语言层面的绝对保证。优化器可能把对象保存在寄存器中，甚至完全消除它，只要可观察行为符合 C 语言规则。

10.4 正常终止与异常终止

从 main 返回等价于把返回值交给正常终止流程，运行库会进行标准规定的退出处理，例如刷新正常打开的缓冲流并调用通过 atexit 注册的函数。

崩溃、强制终止、调用 _Exit 等路径可能不会执行同样的清理流程。不要依赖"操作系统最终会回收进程资源"来代替应用内部正确的文件、锁、事务和持久化处理。

十一、常用命令、高频问答与练习

11.1 GCC 常用命令速查

目的	命令
查看预处理结果	`gcc -E test.c -o test.i`
生成汇编代码	`gcc -S test.c -o test.s`
生成目标文件	`gcc -c test.c -o test.o`
链接多个目标文件	`gcc test.o add.o -o app`
一步构建多文件项目	`gcc test.c add.c -o app`
开启常用警告	`gcc -Wall -Wextra -Wpedantic ...`
加入调试信息	`gcc -g ...`
选择优化级别	`gcc -O0/-O1/-O2/-O3 ...`
定义预处理宏	`gcc -DDEBUG ...`
添加头文件搜索目录	`gcc -Iinclude ...`
添加库搜索目录和库	`gcc ... -Lpath -lname`

-lname 通常表示寻找名为 libname.so 或 libname.a 等符合平台规则的库。具体选择会受到工具链、参数与文件存在情况影响。

11.2 高频问答

Q1：gcc test.c -o app 只做了编译吗？

不是。没有 -E、-S 或 -c 让流水线提前停止时，驱动程序通常会继续完成预处理、编译、汇编和链接。

Q2：.o 里已经有机器码，为什么不能直接运行？

因为它通常还是可重定位目标文件，地址布局没有最终完成，也可能引用其他模块和库中的符号，缺少完整可执行映像所需的信息。

Q3：有函数声明，为什么仍然会出现 undefined reference？

声明只帮助编译器检查名称与调用形式。链接器仍需要在参与链接的目标文件或库中找到对应定义。

Q4：#include 会把 .c 文件也包含进来吗？

预处理器并不禁止包含任意文本文件，但工程上不应通过包含 .c 文件组织模块。应包含头文件声明，并把各 .c 文件独立编译后链接，否则容易产生重复定义、依赖混乱和构建问题。

Q5：为什么头文件里可以放函数定义？

普通具有外部链接的函数定义放进被多个翻译单元包含的头文件，往往会导致重复定义。static inline 等写法有不同链接与内联规则，可以用于头文件，但必须明确理解其语义，不能把"头文件只是声明"当成毫无例外的语法禁令。

Q6：预处理器会检查宏展开后的类型吗？

不会。预处理负责指令和记号变换；宏展开后的 C 代码由后续编译阶段进行语法与类型检查。

Q7：汇编阶段会解决跨文件函数地址吗？

通常不会。汇编器会生成符号与重定位信息，跨目标文件的符号绑定和最终地址修正主要由链接器完成。

Q8：链接成功是否说明函数声明与定义完全一致？

不能这样保证。某些不一致可能被工具链发现，另一些可能因为 ABI 与符号命名方式而隐藏到运行时。让声明来自同一个头文件，并启用警告和链接时优化，有助于更早发现问题。

Q9：静态库与动态库最大的直观区别是什么？

静态库中的所需代码通常在链接时进入产物；动态库通常保持独立，程序记录依赖，在装载或运行过程中解析并映射。二者在部署、体积、更新、加载和符号解析方面各有权衡。

Q10：为什么 Release 版本的调试体验和 Debug 不同？

优化会重排、合并或消除源码层面的变量和控制流。机器执行仍需保持语言规定的可观察行为，但源码行、变量位置和指令之间不再简单对应。

11.3 一套稳定的排错顺序

遇到构建失败时，可以按下面的顺序检查：

记录完整命令与第一条关键诊断；
判断失败发生在预处理、编译、汇编、链接还是运行；
若涉及宏或头文件，生成 .i 查看真实输入；
若涉及类型与语法，先修复最早出现的编译错误；
若涉及未定义符号，确认实现文件或库是否参与链接；
若涉及重复定义，检查头文件是否放入了外部对象或普通函数定义；
若涉及跨文件接口，确认所有使用者包含同一份头文件；
若链接成功但运行失败，转向调试器、日志、断言与 sanitizer；
最后再考虑优化级别、ABI、架构、库版本和平台差异。

11.4 动手练习

为一个最小 hello.c 分别生成 .i、.s、.o，比较文件大小与内容可读性。
在预处理结果中搜索 printf 的声明来自哪个头文件展开片段。
把 Add 的定义从链接命令中移除，记录编译与链接分别在哪一步成功或失败。
在两个 .c 文件中都定义 int g_val = 0;，观察重复定义诊断。
把 g_val 改成 static int g_val = 0;，解释符号可见性为什么发生变化。
使用 nm 或平台对应工具，分别查看 test.o 与 add.o 中 Add 的状态。
修改 add.h 中 Add 的参数类型，确保 add.c 也包含该头文件，观察编译器怎样发现不一致。
开启 -O0 与 -O2 分别生成 .s，比较常量折叠、寄存器使用与函数调用变化。
使用 -g 和 AddressSanitizer 构造一个越界访问，体会"构建成功"和"运行正确"的区别。
画出自己项目从源文件、第三方库到最终可执行程序的依赖图，并标出每个符号由哪个模块定义。

总结

一条 C 程序从源码到运行结果，并不是"点一下运行按钮"那么简单。稳定的理解链路是：

预处理展开构建条件 → 编译理解语言并生成汇编 → 汇编编码机器指令并形成目标文件 → 链接解析符号和重定位 → 运行环境装载、启动、执行与终止。

预处理解决宏、条件编译和头文件展开；编译解决词法、语法、静态语义、优化与代码生成；汇编生成带有节、符号和重定位信息的目标文件；链接则把独立模块与库组织成最终程序。

多文件工程能够成立，是因为每个翻译单元可以独立编译，而头文件为它们提供一致接口，链接器再把引用与定义接起来。extern 只负责声明"符号在别处"，不会替程序创造定义；目标文件中的地址也可能只是待修正信息，最终由链接与装载机制完成连接。

真正掌握这部分知识后，看到报错时就不再只剩一句"编译失败"，而能继续追问：

text 复制代码

是宏和头文件出了问题？
是语法或类型不成立？
是符号没有定义或定义重复？
还是程序已经生成，只在运行时失败？

能够把问题放回正确阶段，就是理解编译和链接最直接、最实用的价值。

【C 语言】编译和链接：从源文件、目标文件到可执行程序完整解析

☕ 写在开篇

文章目录

一、先分清两个世界：翻译环境与运行环境

二、总览：一条 C 程序怎样变成可执行文件

2.1 常见后缀分别表示什么

三、预处理：处理所有以井号开头的指令

3.1 宏展开

3.2 条件编译

3.3 头文件包含

3.4 注释、行号与编译器指令

四、编译：从记号、语法树到汇编代码

4.1 词法分析：把字符切成记号

4.2 语法分析：构造表达式结构

4.3 语义分析：语法正确还不够

4.4 优化与代码生成

五、汇编：从助记符到可重定位目标文件

5.1 为什么目标文件仍不能直接执行

六、多文件项目为什么可以分别编译

6.1 头文件应该放声明

6.2 一个外部对象通常只定义一次

6.3 static 会改变跨文件可见性

七、链接：符号决议、地址布局与重定位

7.1 符号是什么

7.2 重定位到底在"修"什么

7.3 库也参与链接

7.4 声明与定义必须一致

八、亲手走一遍多文件构建流程

8.1 故意制造一个链接错误

8.2 查看目标文件中的符号

8.3 为什么修改头文件可能触发大量重编译

九、四类错误应该怎样定位

9.1 预处理错误

9.2 编译错误

9.3 链接错误

9.4 运行错误

十、可执行文件生成以后发生了什么

10.1 装载程序映像

10.2 运行库先于 main 工作

10.3 程序使用不同存储期的对象

10.4 正常终止与异常终止

十一、常用命令、高频问答与练习

11.1 GCC 常用命令速查

11.2 高频问答

11.3 一套稳定的排错顺序

11.4 动手练习

总结

6.3 `static` 会改变跨文件可见性

10.2 运行库先于 `main` 工作