2、符号表与符号解析：链接的“户籍系统”

说到库链接，绕不开一个核心概念——符号表。

我经常跟团队里的新人说，符号表就是链接器的“户籍系统”。每个目标文件、每个库，里面住了哪些“人”（函数、变量），都登记在册。链接器要干活，第一件事就是查户口。

2.1 符号表长什么样？

说白了，符号表就是一张清单。每个条目记录了一个符号的名字、地址、大小、类型，还有它所在的节区。

你可以用 nm 命令把它打印出来看看。我个人习惯在排查链接问题时，第一件事就是跑 nm。

# 查看目标文件的符号表
$ nm myobject.o
0000000000000000 T func_a
0000000000000010 D global_var
                 U printf
                 C my_weak_symbol

这里每个字母都有含义：

字母	含义	说明
T	Text（代码段）	已定义的全局函数
D	Data（数据段）	已初始化的全局变量
U	Undefined	未定义，需要外部提供
C	Common	弱符号，暂未分配地址

嗯，这里要注意：U 类型的符号，就是链接器要去别处找的“通缉犯”。如果最后找不到，就会报“undefined reference”错误。

2.2 强符号 vs 弱符号

这个概念特别重要。我当年在做一个嵌入式项目时，就因为这个吃了大亏。

强符号：函数名、已初始化的全局变量。一个强符号在整个程序中只能出现一次。

弱符号：未初始化的全局变量（C语言中），或者用 __attribute__((weak)) 声明的符号。

看个例子你就明白了：

// file1.c
int global_var = 42;  // 强符号
void func() {}        // 强符号

// file2.c
int global_var;       // 弱符号（未初始化）
void func() {}        // 强符号 —— 重复定义！链接报错

如果两个文件里 func 都是强符号，链接器会直接报错。但如果是弱符号呢？

// file1.c
__attribute__((weak)) void func() {
    // 默认实现
}

// file2.c
void func() {
    // 用户自定义实现
}

这时候，强符号 func 会覆盖弱符号。链接器最终用的是 file2.c 里的版本。

2.3 符号解析规则

链接器解析符号时，遵循一套固定的流程。我把它总结成三步：

1. 收集所有符号：扫描所有目标文件和库，建立全局符号表
2. 匹配定义：对每个未定义符号（U），在已定义的符号中查找
3. 处理冲突：按强/弱规则决定最终使用哪个定义

这里有个坑，我曾经踩过——链接顺序。

再来看一个更复杂的场景——同名弱符号的抉择。

// a.c
int x __attribute__((weak)) = 4;  // 弱符号，大小4字节

// b.c
double x __attribute__((weak));    // 弱符号，大小8字节

// main.c
#include <stdio.h>
extern int x;  // 声明为int
int main() {
    printf("%d\n", x);
    return 0;
}

猜猜结果是什么？

链接器会选择占用空间最大的那个弱符号——也就是 b.c 里的 double（8字节）。但 main.c 把它当作 int（4字节）来用，这就出大问题了。数据会被截断，或者读到错误的值。

2.4 符号解析的完整流程

为了让你更直观地理解，我画了一张流程图：

这个流程看起来简单，但实际项目中往往很复杂。比如多个库之间有循环依赖，或者同一个符号在多个库中都有定义。这时候就需要你理解链接器的“单次扫描”特性，合理调整库的顺序。

2.5 实战建议

• 用 nm 排查符号问题：遇到链接错误，先跑 nm -u 看未定义符号，再跑 nm -C 看 C++ 符号的 demangle 版本。
• 慎用弱符号：弱符号虽然灵活，但容易引发隐蔽的 bug。我建议只在库的默认实现中使用，并且类型必须统一。
• 注意链接顺序：库放在目标文件后面，必要时用 --whole-archive 强制链接整个库。

符号表这块，说白了就是链接器的“户籍管理”。搞懂了它，你就掌握了链接的命脉。下次遇到链接错误，别慌，先查户口。