第4章：链接的职责：符号解析与重定位

编译四阶段跑完，最后一棒交给链接器：把散落各处的目标文件拼成能运行的程序。这一章拆开链接器的两大任务——符号解析与重定位，再用三个真实报错，练一遍福尔摩斯式的排错

4.1 链接器到底做什么：符号解析与重定位

上一章我们解剖了目标文件（.o，编译与汇编的产物，里面是机器指令和数据的"半成品"）。但一个 .o 是跑不起来的——真实程序由几十上百个源文件编译而来，每个源文件只生成了自己的那一小块。把它们拼成一个整体、让互相的调用都对上号的，就是链接（linking，把不同代码和数据收集、组合成一个可执行文件的过程）和链接器（linker，干这件事的程序，GCC 体系里是 ld）。说人话：编译是各自为战，链接是战后收编。链接器有两大任务——符号解析（symbol resolution）和重定位（relocation）。

先造一个最小案例。两个文件：math.cpp 定义计算平方的函数，use_math.cpp 调用它。注意 use_math.cpp 里只有一行声明（declaration，只说明"存在这么个函数"）而没有定义（definition，函数体本身）——这正是链接器要解决的第一个问题：谁来兑现这张"欠条"？

// math.cpp —— 定义（definition）：函数体在这里
int square(int x) {
    return x * x;
}

// use_math.cpp —— 只有声明（declaration），没有定义
#include <cstdio>
int square(int x);       // 声明：告诉编译器"有这函数"，但没给函数体

int main() {
    std::printf("%d\n", square(6));
    return 0;
}

# 先把两个源文件分别编译成目标文件，再链接（实测通过，输出 36）
g++ -c math.cpp -o math.o
g++ -c use_math.cpp -o use_math.o
g++ use_math.o math.o -o app
./app
36

任务一：符号解析。符号（symbol）就是函数名、变量名在二进制世界里的"身份证"——编译时，源文件里的每个函数和全局变量都会被登记成一个符号，记进目标文件的符号表（symbol table，一张"名字 → 类型/地址"的登记簿）。链接时，use_math.o 引用了 square 却没定义它，math.o 定义了 square 却没被引用——符号解析做的，就是把每个"引用"和它的"定义"对上号。用 nm（列出目标文件符号表的工具）看这两个文件，一目了然：

# nm 列出符号表：U = undefined（未定义引用），T = 已定义的代码符号
$ nm use_math.o
                 U __Z6squarei        # square(int) 的"修饰名"——有人引用，没人定义
0000000000000000 T _main              # main 已定义，住在 .text 节
                 U _printf            # 连 printf 也是未定义——它住在 C 标准库里

$ nm math.o
0000000000000000 T __Z6squarei        # 定义在这里！符号解析就是把它俩对上号

任务二：重定位。编译器和汇编器生成代码时有个偷懒的前提：每个 .o 都假设自己从地址 0 开始。可两个 .o 拼在一起，不可能都住在地址 0。所以链接器把每个符号定义安排到最终的内存位置，再回去修改所有引用它的地方，让它们指向这个新位置——这个"改地址"的过程就是重定位。名字里的"位"是位置的位：符号解析回答"你是谁"，重定位回答"你在哪"。

# 链接前：use_math.o 里对 square 的调用是个占位地址
use_math.o（从地址 0 开始）          math.o（也从地址 0 开始）
  0x0000: call 0x00000000          0x0000: square 的机器指令...

# 链接后：合并进同一个地址空间，引用被改写为真实地址
可执行文件 app
  0x1000: call 0x1040  ->  square 的代码被安排在 0x1040，引用已改指
  0x1040: square 的机器指令...

# 链接器的完整工作流（把"素材块"按规则拼成成品）
# ① 收集：把命令行上的 .o 和库里的 .o 全部收进来
# ② 符号解析：把每个引用和定义对上号（对不上的 = undefined reference）
# ③ 重定位：合并各节，给符号分配最终地址，改写所有引用点
# ④ 产出：可执行目标文件（或共享库）
输入(.o, .a, .so) --> 链接器 --> 输出(可执行文件/共享库)

4.2 链接发生的三个时机：编译时 / 加载时 / 运行时

链接不一定非得发生在"编译那一下"。素材里说得明白：链接可以发生于编译时（源代码被翻译成机器代码时），也可以发生于加载时（程序被加载器装入内存执行时），甚至发生于运行时（由应用程序自己来执行）。三个时机对应三种链接形态，也对应三种不同的"打包程度"：编译时链接把一切钉死，加载时链接留一半到启动时再解，运行时链接则把决定权交给程序本身。

# ① 编译时链接：链接器在生成可执行文件时，把静态库（.a）里的成员并入
g++ use_math.o libmath.a -o app

# ② 加载时链接：可执行文件里只记一个"待解析"标记，
#    程序启动时由动态链接器把共享库（.so）装进来并解析符号
g++ use_math.o -lmath -o app
ldd ./app        # Linux：查看这个程序加载时需要哪些共享库
otool -L app     # macOS：等价的查看命令

# ③ 运行时链接：程序自己调 dlopen 现装现用（第 5 章的主角）
void* h = dlopen("./libmath.so", RTLD_LAZY);

# 加载时链接的幕后流程（.so 的符号在第 6 章虚拟地址空间里继续展开）：
./app --启动--> 加载器(loader) --> 动态链接器(ld-linux.so)
                 # 按可执行文件里的 NEEDED 列表逐个加载 .so
                 # 把 app 里未定义的符号与 .so 导出的符号对上号
                 # 全部就绪，才跳进 main()

眼见为实。上面链接出的 good 程序，用 otool -L 能看到它启动时要加载的动态库清单；在 Linux 上，等价的 ldd 会显示类似的结构——程序自己写的代码之外，libc 这类"基础设施"都是靠加载时链接进来的，这也解释了 4.1 节里 printf 为什么是 U 符号：它到加载那一刻才被兑现。

# macOS 实测：otool -L 显示 good 启动时要加载的动态库
$ otool -L good
good:
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 2100.43.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)

# Linux 上等价的 ldd（canonical 输出示例）
$ ldd ./app
        linux-vdso.so.1 (0x00007ffe2c3f9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8e4a200000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8e4a430000)

4.3 为什么要懂链接：五个好处

对入门课堂里构造小程序的学生来说，链接器"安静地"处理一切，从来不是个议题——一个小程序就一两个文件，链接几乎不可能出错。可一旦进入真实项目，不懂链接的代价会成倍放大。素材给了五个好处：① 帮你构造大型程序——大型项目最常见的链接错误是"缺模块、缺库、库版本不兼容"，不懂"链接器如何解析引用"，这些报错永远像天书；② 帮你避免危险的编程错误——链接器在默认情况下会不动声色地放行某些错误的定义，让程序带着雷运行；③ 帮你理解作用域规则——全局/局部、static 到底意味着什么，答案不在语法书里，而在符号表里；④ 帮你理解系统概念——加载器、动态链接器、虚拟内存都绕着链接转；⑤ 帮你开发共享库——现代软件靠共享库在运行时升级、打补丁。②和③，我们用两个真实实验证明。

/* tent_a.c —— C 语言：两个文件都写"不带初始化"的全局变量 */
int g_counter;

/* tent_b.c */
#include <stdio.h>
int g_counter;
int main(void) {
    printf("%d\n", g_counter);
    return 0;
}

# 实测（本机）：C 语言竟然链接成功，还打印了 0！
$ gcc tent_a.c tent_b.c -o tent && ./tent
0

# 同样的两个文件，用 g++ 编译：立刻报错（macOS 实测）
$ g++ tent_a.c tent_b.c -o tentcpp
duplicate symbol '_g_counter' in:
    .../tent_a-xxx.o
    .../tent_b-xxx.o
ld: 1 duplicate symbols

第二个实验：static 的作用域。两个文件都声明 static int counter——名字一模一样，但它们是两个完全独立的符号，谁也不知道谁的存在。用 nm 看，两个 .o 里各有一个小写 d（local，局部数据符号）的 counter：static 把符号的"可见范围"锁死在本文件，这就是"内部链接"（internal linkage）在符号表里的样子。

// loc_a.cpp                     // loc_b.cpp
static int counter = 100;    static int counter = 1;   // 同名，互不相干

int bump_a() { return ++counter; }   int bump_b() { return counter * 10; }

# 实测：两个 .o 里各有各的 counter，地址不同，互不干扰
$ nm loc_a.o | grep counter
000000000000006c d __ZL7counter
$ nm loc_b.o | grep counter
0000000000000014 d __ZL7counter

# 把两个文件一起链接、运行（本机实测）：
$ g++ loc_a.cpp loc_b.cpp -o loc && ./loc
203   # bump_a 的 counter 从 100 加到 102，bump_b 的 counter 一直是 1

4.4 实战排错一：undefined reference

现在把方法论用起来。福尔摩斯的原则：排除所有不可能，剩下的就是真相——排错第一步永远是"确认这是什么错误"，而不是盯着报错乱猜。链接错误和编译错误长得像，性质完全不同：编译错误是"代码写错了"（语法/类型），链接错误是"找不着"（有引用，没定义）。下面这个例子，编译阶段安然无恙，链接阶段当场爆炸：

// undef.cpp —— 声明了 square，却从未定义它
#include <cstdio>

int square(int x);   // 只有声明，没有定义

int main() {
    std::printf("%d\n", square(5));
    return 0;
}

# 编译：没有任何问题（-c 只做到汇编，链接是后话）
$ g++ -c undef.cpp -o undef.o

# 链接：报错了。Linux（g++）的经典报错长这样：
$ g++ undef.o -o undef
/usr/bin/ld: undef.o: in function `main':
undef.cpp:(.text+0x14): undefined reference to `square(int)'
collect2: error: ld returned 1 exit status

# 本机 macOS（Apple clang）实测，同一个错误长这样：
$ g++ undef.cpp -o undef
Undefined symbols for architecture arm64:
  "square(int)", referenced from:
      _main in undef-309db3.o
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

两句话就能看懂报错：Linux 版直说 "undefined reference to `square(int)'"，macOS 版说 "Undefined symbols: square(int), referenced from _main"——意思完全一样：main 里引用了一个符号，但链接器在所有输入里都找不到它的定义。排查思路按"排除不可能"逐条过：① 符号真的存在吗？用 nm 看目标文件，确认 U 符号是谁；② 定义在哪个文件/库里？全工程搜一遍定义；③ 定义所在的文件/库，链接命令带上没有？顺序对不对？（顺序问题 4.5 节专治）；④ 名字对吗？注意 C++ 修饰名和 extern "C"；⑤ 被宏/条件编译裁掉了？比如定义被 #ifdef 包住而宏没开。

# 排查第一刀：nm 看符号到底存不存在（本机实测）
$ nm undef.o
                 U __Z6squarei        # 果然：U 符号，引用存在，定义缺失
0000000000000000 T _main

# 排查第二刀：全工程搜定义（.cpp 里有没有 square 的函数体）
$ grep -rn "square" . --include=*.cpp

# 修复：补上定义（或把 libmath.a 加进链接命令），重编重链（实测输出 25）
$ g++ undef_fixed.cpp -o undef && ./undef
25

4.5 实战排错二：multiple definition 与链接顺序

第二个高频链接错误：multiple definition（多重定义，同一个符号被定义了不止一次）。它的报错逻辑和 undefined reference 正好相反——那是"要的没有"，这是"给的太多"。最经典的场景：两个源文件都定义了同名全局变量（还记得 4.3 节 C++ 的严格规则吗？）：

// dup_a.cpp —— 全局变量 g_counter 的定义之一
int g_counter = 0;

// dup_b.cpp —— g_counter 的另一个定义！
#include <cstdio>
int g_counter = 0;
int main() {
    std::printf("%d\n", g_counter);
    return 0;
}

# Linux（g++）经典报错（canonical 格式）：
$ g++ dup_a.cpp dup_b.cpp -o dup
/usr/bin/ld: dup_b.o: in function `main':
dup_b.cpp:4: multiple definition of `g_counter'; dup_a.o:dup_a.cpp:1: first defined here
collect2: error: ld returned 1 exit status

# 本机 macOS 实测，同一个错误长这样：
$ g++ dup_a.cpp dup_b.cpp -o dup
duplicate symbol '_g_counter' in:
    .../dup_b-627e5f.o
    .../dup_a-de48df.o
ld: 1 duplicate symbols
clang++: error: linker command failed with exit code 1

修复的思路顺着"为什么会有两个定义"展开：① 本意是共享？留一个定义，其他文件用 extern 声明引用它；② 本意是各自独立？加 static 变成内部链接（见 4.3 节），或包进 namespace 用名字隔离；③ 是头文件里的定义被多个 .cpp 包含？把定义挪进 .cpp，头文件只留声明——这也是"头文件里不要放定义"这条纪律的底层原因。注意：多个 .cpp 包含同一头文件不会触发这个错误（预处理后每个编译单元各有一份拷贝）；报错只发生在"不同编译单元各定义了一份"时。

第二个坑：链接顺序。Linux 的 GNU ld 对命令行上的文件做单遍、从左到右扫描：遇到目标文件（.o）全部并入；遇到静态库（.a）只抽取"当前尚未解析的引用"所需的成员，抽完即过、不回头。所以库必须放在引用它的目标文件之后——把 libmath.a 放到 use_math.o 前面，扫描到库时 square 还没被引用，库成员一个都不抽，等轮到 use_math.o 时引用才出现——结果就是 4.4 节的报错换了个马甲重新登场：

# 库放对位置：成功（实测输出 36）
$ g++ use_math.o libmath.a -o app && ./app
36

# 库放错位置（Linux）：报 undefined reference！
$ g++ libmath.a use_math.o -o app
/usr/bin/ld: use_math.o: in function `main':
use_math.cpp:(.text+0x14): undefined reference to `square(int)'
collect2: error: ld returned 1 exit status

# 本机 macOS 实测：两种顺序居然都能过！（ld64 用全局符号表，不按顺序扫）
$ g++ libmath.a use_math.o -o bad && ./bad
36

4.6 小结：链接器的世界地图

把这一章的碎片拼成一张图：编译四阶段走完，每个 .o 都是"从地址 0 开始、带着一堆欠条"的半成品；链接器收编它们，符号解析把欠条兑现（U 变 T），重定位给每个人安排最终地址；成品可执行文件在加载时还要靠动态链接器再解一轮 .so 的账。整条链路里，链接器是承上启下的总装配车间——这也是为什么第 1 章那张流程图里，链接是最后一棒。

# 链接器世界地图：从源码到运行的完整链路
源码 --编译--> .o --符号解析+重定位--> 可执行文件 --加载--> 进程
      (第2/3章)    （本章 4.1）        (第5章:库)  (第6章:内存)

# 报错对照表（遇到就翻这里）：
undefined reference / Undefined symbols  = 有引用，没定义        --> 4.4
multiple definition / duplicate symbol   = 有引用，定义多了      --> 4.5
库顺序错（Linux）                         = 扫描时机不对          --> 4.5
symbol lookup error（加载时）             = 运行时库对不上        --> 第5章

# 福尔摩斯式排错四步（链接错误专用）：
1. 确认阶段：是 ld 的错，不是 cc1 的错（编译错误 vs 链接错误）
2. 确认符号：nm 看 U/T，这个符号到底有没有定义
3. 确认来源：定义在哪个文件/库？链接命令带上没有？顺序对不对？
4. 动手修复：补定义 / 加库 / 调顺序，一次改一处，改完立刻重链

下一站，第 5 章把"库"补完：静态库（.a）怎么打包、共享库（.so）怎么用 -fPIC 和 -shared 生成、dlopen 怎么在运行时现装现用、binutils 工具箱怎么解剖一切目标文件——4.2 节那张"三个时机"的表，会在那里逐一落地成命令。到那时你会发现，本章学到的符号与重定位，正是理解库的全部地基。

$ nm undef.o
                 U __Z6squarei
0000000000000000 T _main
                 U _printf