3、GCC/G++链接器基础

说实话，很多C/C++开发者写了几年代码，编译链接报错时还是一脸懵。我见过太多人对着undefined reference抓耳挠腮，最后靠运气乱试一通。今天咱们就把GCC链接器的几个核心选项彻底讲透。

3.1 链接器常用选项：-l、-L、-I

这三个选项，说白了就是告诉链接器三件事：找谁、去哪找、怎么找。

-I（大写i）：指定头文件搜索路径

这个其实不是链接器选项，是编译器的。但我习惯放在一起讲，因为很多人把-I和-L搞混。-I告诉编译器去哪里找#include的头文件。

gcc -I/usr/local/include -I./include main.c -o main

嗯，这里要注意：-I指定的路径，优先级高于系统默认路径。我曾经遇到一个坑——项目里自己写了个string.h，结果-I.把系统头文件覆盖了，编译出来一堆诡异错误。

-L：指定库文件搜索路径

这个才是链接器用的。告诉链接器去哪里找.a或.so文件。

gcc main.o -L./lib -L/usr/local/lib -lfoo -o main

-l（小写L）：指定要链接的库名

注意：-lfoo会去找libfoo.a或libfoo.so。这是GCC的命名约定——自动加上lib前缀。

3.2 -shared 与 -static：动态 vs 静态链接

这两个选项决定了你的程序是「轻装上阵」还是「全副武装」。

-shared：生成动态库

编译动态库时用：

gcc -fPIC -shared foo.c -o libfoo.so

-fPIC生成位置无关代码，这是动态库必须的。我个人习惯写动态库时永远带上它，省得后面出问题。

-static：静态链接

把所有库都打包进可执行文件：

gcc main.c -static -lfoo -o main_static

静态链接的好处是「一次编译，到处运行」，坏处是文件体积大。我记得有个项目，静态链接后从500KB膨胀到5MB，但部署时确实省心不少。

3.3 链接顺序问题：一个让人抓狂的坑

这个问题我至少被问过20次。为什么明明链接了库，还是报undefined reference？

核心规则：GCC链接器是从左到右扫描的。如果一个库定义了符号，它必须出现在引用该符号的目标文件之后。

# 正确顺序：main.o引用libfoo.a中的函数
gcc main.o -L. -lfoo -o main

# 错误顺序：libfoo.a在main.o之前，链接器扫描时还不知道需要什么
gcc -L. -lfoo main.o -o main  # 可能报错！

为什么会这样？因为链接器维护一个「未解析符号表」。扫描main.o时，发现需要foo_func，把它记下来。然后扫描libfoo.a时，发现里面有foo_func，就把它链接进来。反过来，先扫libfoo.a时，发现里面一堆函数，但不知道哪些有用，可能就跳过了。

我有个血泪教训：一个项目有20多个静态库，链接顺序写错，折腾了两天才发现是-lmath放在了-lengine前面。从那以后，我写Makefile时都会用LDLIBS变量统一管理顺序。

3.4 链接脚本简介

链接脚本（Linker Script）是链接器的「指挥图」。平时我们用默认的就行，但做嵌入式开发或特殊内存布局时，就得自己写了。

默认链接脚本可以用ld --verbose查看，内容很长。核心结构大概这样：

SECTIONS
{
    .text : { *(.text) }  /* 代码段 */
    .data : { *(.data) }  /* 已初始化数据段 */
    .bss  : { *(.bss) }   /* 未初始化数据段 */
}

自定义链接脚本时，用-T指定：

gcc main.o -T my_script.ld -o main

说实话，我平时很少手写链接脚本。但有一次做ARM裸机开发，需要把代码放到0x80000000地址，中断向量表放到0x00000000，这时候链接脚本就是救命稻草了。

3.5 知识体系总览

下面这张图总结了GCC链接器的核心知识点，我画的时候特意把「链接顺序」放在中间——因为这是最容易出问题的地方。

3.6 实战建议

最后分享几个我自己的习惯：

• 写Makefile时：把-L和-l分开写，LDFLAGS放-L，LDLIBS放-l，顺序一目了然。
• 调试链接错误时：先用nm或objdump检查库中到底有没有需要的符号。我经常看到有人对着undefined reference折腾半天，结果发现库根本没编译对。
• 混合链接时：明确哪些库要静态、哪些要动态，用-Wl,-Bstatic和-Wl,-Bdynamic包裹。