动态链接这事儿说大不大说小不小。我见过不少人编译个 C 程序报undefined reference会解决一到了运行时报error while loading shared libraries就抓瞎更别提让他解释PLT、GOT、延迟绑定这些词到底在干什么。其实动态链接就是程序从源码变成进程的最后一个关键环节搞懂它很多莫名其妙的运行时报错你一眼就能看穿。这篇文章我打算从“为什么需要动态链接”开始讲把地址无关代码、GOT/PLT、动态链接器的工作流程、搜索路径全部拆开揉碎最后带你自己动手做一遍实验亲自观察一次动态链接的完整过程。适合 C/C 开发者、对系统底层好奇的运维同学以及所有被链接错误折磨过的人。我尽量说人话但底层机制该讲透的地方绝不绕弯子。1. 动态链接到底解决什么问题1.1 从静态链接说起要理解动态链接必须先知道静态链接是怎么回事。早期程序开发基本就是静态链接你写了一个main.c调用了一个printf编译链接的时候链接器会把printf的机器码从libc.a这个静态库里直接拷贝一份塞进你的可执行文件里。最后生成的可执行文件是自包含的拿到任何一台同架构的 Linux 机器上都能跑这是它最大的优点。但缺点很致命假如系统里有 100 个程序都调用了printf那么磁盘上就有 100 份printf的机器码副本。这还只是磁盘占用的问题更麻烦的是内存。每个程序运行的时候这 100 份printf会被各自加载到内存里物理内存中就存了 100 份一模一样的代码。按现在动辄几百 MB 的库来算这种浪费是难以接受的。另外还有一个维护性的问题。如果printf内部发现了一个安全漏洞需要修复静态链接的世界里你没有任何办法——除非把系统里所有依赖这个函数的程序全部重新编译一遍再重新分发。这在一个大型系统里几乎是不可能完成的任务。1.2 动态链接的设计思路动态链接的思路完全反过来了。可执行文件里不再存放库函数的机器码只存放一个“引用说明”——告诉系统我这个程序需要用到哪个共享库里的哪个符号。真正的代码留在.so文件里程序运行之前由系统里一个叫做动态链接器的程序去找到这些.so把它们加载进内存再把可执行文件里的引用和库里的实际地址关联起来。这个方案带来的好处是肉眼可见的。第一磁盘和内存都省了100 个程序共享一份libc.so物理内存里只放一份.text段大家通过页表映射共享它内存占用从 100 份变成 1 份加一些私有的数据段。第二升级变得无比简单修复了libc.so的漏洞直接替换这个.so文件重启依赖它的程序就生效了不需要重新编译任何业务代码。不过别高兴太早动态链接不是免费的午餐。它引入了新的运行时开销——程序启动时动态链接器要干活符号的解析也需要时间它引入了新的失败模式——运行时报“找不到 .so”、报“undefined symbol”这些都是静态链接时代不存在的错误。你写代码的时候编译通过了不代表程序就能跑起来这就是动态链接给所有开发者的“惊喜”。1.3 两种链接方式的对比维度静态链接动态链接可执行文件大小大包含全部依赖代码小只包含引用信息内存占用每个进程各存一份共享库物理内存共用一份启动速度快直接运行慢需要动态链接器解析升级维护需要重新编译所有依赖者替换 .so 即可兼容性风险低自包含高依赖系统库版本部署便利性拷贝即用需要带上所有依赖库从这张表能看出来动态链接不是在所有场景都优于静态链接。做嵌入式开发、做容器镜像的朋友经常会有意识地使用静态链接就是为了避免动态库依赖带来的部署噩梦。理解了这个背景再看后面的机制就顺理成章了。2. 动态链接的三大核心机制2.1 地址无关代码PIC动态链接面临一个根本性的问题.so文件在被加载进内存的时候加载地址是不确定的。同一个.so在进程 A 里可能被加载到0x7f0000000000在进程 B 里可能被加载到0x7f1111111000。如果代码里面直接写了绝对地址那这个.so只能被加载到固定位置否则一运行就崩。解决办法就是编译时加-fPIC。PIC 是 Position Independent Code 的缩写它的核心思想是代码段里不直接引用绝对地址所有对全局变量和函数的访问都通过一个间接层——全局偏移表GOT来完成。代码里存的只是一个“偏移量”程序加载后动态链接器算出.so的真实基地址再把这个基地址加上偏移量填充进 GOT代码通过 GOT 间接访问数据就和加载地址无关了。你会问为什么链接器不直接修改代码里的地址因为代码段在进程间是共享的如果每个进程都要修改代码段里的地址就破坏了共享性必须为每个进程复制一份私有的代码段副本。而 GOT 是数据段每个进程可以有自己的一份修改 GOT 不影响共享的代码段。这就是“地址无关”的精髓——共享代码私有数据。2.2 GOT 与 PLT 的分工很多人把 GOT 和 PLT 混在一起讲其实它们分工完全不同。GOT 是全局偏移表它存放的是地址数据全局变量的地址、函数的真实地址。而 PLT 是过程链接表它存放的是一小段跳转指令是给函数调用准备的“跳板”。简单梳理一下函数调用的路径。你写的代码调用add(1, 2)编译后生成的指令是call addplt。addplt是 PLT 里的一项它的内容大致是先跳转到 GOT 里记录的地址如果 GOT 里还没填上add的真实地址就触发动态链接器去解析解析完再填回 GOT如果已经填过了就直接跳到目标函数。这个设计精妙在它把“调用函数”这个行为统一变成了“查 GOT”而 GOT 的内容是运行时才确定的完美配合 PIC 方案。为什么要把全局变量和函数分开处理因为两者的访问模式不同。全局变量是直接读数据编译器会把对全局变量的访问编译成通过 GOT 间接寻址的指令比如mov rax, [rip GOT_offset]。函数则是通过 PLT 跳板加一层间接跳转。实际调试的时候你用objdump -d看一个动态链接的可执行文件会看到大量plt结尾的调用指令那就是在走 PLT 这条路径。2.3 延迟绑定如果程序一启动就把所有依赖库里的所有函数都解析好那启动速度会慢得吓人。实际上很多程序用到的库函数只占库导出函数的一小部分比如一个程序可能只用了libc.so里的 20 个函数而 libc 导出了几千个符号。全部解析明显不划算。于是出现了延迟绑定也叫懒绑定。它的思路是函数第一次被调用的时候才去解析真实地址后面再调用就直接命中。实现方式就是 PLT 和 GOT 配合——GOT 里初始存放的是 PLT 下一行指令的地址而不是真实函数的地址。第一次调用的时候程序会跳到 PLTPLT 跳到 GOT发现 GOT 里存的是 PLT 下一条指令于是相当于跳到了 PLT 里的解析代码由它把真实地址解析出来并写回 GOT然后再跳转到真实函数。第二次调用GOT 里已经是真实地址了一条指令就直接过去了。你可以用环境变量LD_BIND_NOW1来关闭延迟绑定让动态链接器在程序启动的时候就把所有符号解析完。这通常用于安全敏感的场景因为延迟绑定意味着 GOT 在运行期会被写入如果程序有漏洞攻击者可能利用 GOT 覆写来劫持控制流。后面的实验部分我会带你亲眼观察这个由“未解析”到“已解析”的变化。3. 动态链接器的工作流程与搜索路径3.1 编译阶段写入了什么动态链接不是运行时的独角戏它从编译阶段就开始准备了。当你执行gcc -fPIC -shared -o libfoo.so foo.c的时候编译器和链接器会生成一个特殊的 ELF 文件里面包含一个动态段记录了各种元信息。你可以用readelf -d查看这个动态段。里面会有NEEDED条目标明这个.so依赖哪些其他库有SONAME条目相当于这个库的“身份证名字”程序记录依赖时记的是 SONAME 而不是文件名这样文件名改了只要 SONAME 不变程序照样能找到它可执行文件里还会有RPATH或RUNPATH预先指定搜索库的路径。还有一个容易被忽略的东西叫作.interp段。它记录了动态链接器本身的路径在 Linux 上一般是/lib64/ld-linux-x86-64.so.2。内核加载可执行文件的时候会先读这个段找到动态链接器把它也加载进进程然后把控制权交给它而不是直接交给程序的入口函数。这也就是说动态链接的程序真正意义上的“第一个执行者”是动态链接器。3.2 加载阶段动态链接器做了什么动态链接器的工作可以分成几步。第一步它要先把自己“安顿好”——因为动态链接器本身也依赖一些库这有个鸡生蛋的问题动态链接器在编译时使用了特殊技巧它内部的依赖在加载的第一步就要手工处理好这部分非常底层一般开发者不用深究。第二步它读取可执行文件的动态段找出所有NEEDED条目逐一把依赖的共享库加载进内存。库本身又有自己的依赖所以这是一个递归的过程最终构建出一张完整的依赖图。加载库的过程就涉及路径搜索。第三步就是重定位和符号解析。动态链接器遍历每个库和可执行文件的重定位表根据符号表找到每个符号的真实地址然后填充 GOT 和其他需要修正的位置。这一步是最耗时的。做完这些之后它才调用每个库的初始化函数最后跳转到程序的入口_start程序正式开始执行。3.3 搜索路径的顺序动态链接器查找共享库的路径有一套明确的顺序搞懂这个顺序大部分“找不到库”的问题都能自己解决。我按优先级从高到低列出来DT_RPATH可执行文件动态段里记录的绝对路径已废弃不推荐使用。LD_LIBRARY_PATH环境变量指定的路径列表。DT_RUNPATH可执行文件动态段里记录的路径优先级比LD_LIBRARY_PATH低。/etc/ld.so.cache这是ldconfig生成的缓存文件记录了系统已知的共享库位置。默认目录一般是/lib、/usr/lib64 位系统还有/lib64、/usr/lib64。有一个很关键且容易被忽略的规则DT_RPATH只在它自身存在时生效而且它的优先级高于LD_LIBRARY_PATH而DT_RUNPATH是在链接时用-Wl,-rpath加的新机制它只影响它所在这个库或可执行文件的依赖查找不影响库的依赖。所以如果你在可执行文件上设了DT_RUNPATH它的依赖库再去查找自己的依赖时DT_RUNPATH不会传递给下一级这时候还是得靠LD_LIBRARY_PATH或者系统缓存。注意LD_LIBRARY_PATH在 setuid 和 setgid 的程序上会被内核和动态链接器直接忽略因为环境变量太容易被利用了。遇到 suid 程序报找不到库别想着靠环境变量解决要么装到系统目录要么重新编译指定 RUNPATH。4. 实操亲手观察一次动态链接4.1 准备实验文件理论讲再多不如自己跑一遍。我这里准备两个文件一个共享库一个可执行程序// libmath.c #include stdio.h int add(int a, int b) { int result a b; printf(add called, result %d\n, result); return result; }// main.c #include stdio.h extern int add(int a, int b); int main() { int sum add(3, 4); printf(sum %d\n, sum); return 0; }这个例子足够简单但完整覆盖了函数调用、全局变量访问打印、标准库依赖这些动态链接的核心场景。先编译共享库再编译可执行程序gcc -fPIC -shared -o libmath.so libmath.c gcc -o app main.c -L. -lmath注意第二行命令里的-L.是告诉编译期的链接器在当前目录找libmath.so-lmath是链接libmath.so的缩写形式。不加-L.的话库在默认搜索路径里找不到编译就会报错。4.2 读取 ELF 信息先用readelf看看可执行文件的动态段readelf -d app | grep -E NEEDED|RPATH|RUNPATH正常情况下你会看到类似这样的输出0x0000000000000001 (NEEDED) 共享库[libmath.so] 0x0000000000000001 (NEEDED) 共享库[libc.so.6]这说明app的动态段里只是记录了依赖关系并没有包含add函数的任何代码。再看一下.interp段readelf -l app | grep INTERP输出会显示动态链接器的路径比如/lib64/ld-linux-x86-64.so.2。这个路径就是内核加载完app之后要去加载的动态链接器的位置。4.3 观察 PLT 和 GOT用objdump -d反汇编app重点看main函数和 PLT 段objdump -d app | grep -A 20 main:你会看到对add的调用不是call add 的地址而是call 401030 addplt。跳到了 PLT 段。再单独看 PLTobjdump -d app | grep -A 10 addplt:输出大致是这样0000000000401030 addplt: 401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 404018 addplt0x18 401036: 68 00 00 00 00 push $0x0 40103b: e9 e0 ff ff ff jmp 401020 addplt0xfffffffffffffff0这段就是延迟绑定的入口。第一行跳转到 GOT 里记录的地址注释里的404018就是这个函数的 GOT 条目地址。第一次执行的时候GOT 里存的是下一条指令的地址401036于是跳回来执行push $0x0——这个 0 是符号在重定位表里的序号——然后跳到 PLT 的第一条统一入口动态链接器根据序号去解析add的真实地址写回 GOT。4.4 用 LD_DEBUG 观察运行时的解析过程GLIBC 的动态链接器内置了一个调试开关LD_DEBUG能打印出内部的每一个步骤。这是理解动态链接最直观的工具。先看libs查看库的加载顺序LD_DEBUGlibs ./app输出会列出app依赖的libmath.so、libc.so.6等被依次加载的过程包括它们最终被映射到的内存地址。再看bindings观察符号是怎么绑定的LD_DEBUGbindings ./app你会看到add这个符号在第一次被调用时完成绑定。还有个reloc选项可以观察重定位的细节LD_DEBUGreloc ./app输出量很大但你能看到动态链接器逐条处理重定位表项把符号地址写入 GOT 的全过程。我建议你实际敲一遍这些命令输出比任何文字都更有说服力。LD_DEBUG还支持help参数列出所有可用选项适合自己玩。4.5 搜索路径实验现在做一个小实验把libmath.so从当前目录移走再运行appmv libmath.so /tmp/ ./app你会得到经典的报错./app: error while loading shared libraries: libmath.so: cannot open shared object file: No such file or directory然后试试用环境变量救回来LD_LIBRARY_PATH/tmp ./app程序又能跑了。这就是LD_LIBRARY_PATH发挥作用的过程。但如果我重新编译把路径写死进程序里gcc -o app main.c -L. -lmath -Wl,-rpath,/tmp ./app再把/tmp/libmath.so删掉程序照样报错。-Wl,-rpath路径虽然印在了 ELF 里但库里没有就是没有搜索路径再正确也找不到文件。如果把库放进默认搜索目录/usr/lib或者/usr/local/lib然后运行ldconfig更新缓存即使不设置环境变量程序也能找到这就是生产环境最常见的部署方式。5. 常见问题与排查技巧5.1 找不到共享库这是动态链接最常见的问题报错长得都一样./app: error while loading shared libraries: libxxx.so: cannot open shared object file: No such file or directory排查思路分三步走。第一步用ldd app看所有依赖的库哪些找不到输出里带“not found”字样的就是问题所在。第二步确定这个库在系统里到底有没有用find / -name libxxx.so*全局搜一下。第三步如果库确实存在但没在默认搜索路径里有三种解法临时调试用LD_LIBRARY_PATH长期使用用ldconfig 配置文件打包部署用-Wl,-rpath把相对路径比如$ORIGIN/lib写进 ELF。提示ldd本身不是万能的它会调用动态链接器来解析依赖。如果一个库是为不同架构编译的ldd可能报错或者输出一些奇怪的提示这时候用readelf -d配合readelf -h检查架构更可靠。5.2 undefined symbol 的错误运行时报undefined symbol: xxx比找不到库更难排查因为它意味着库文件找到了但某个符号在它的依赖项里找不到定义。常见原因有三个第一个是链接顺序问题使用静态库时顺序不对会导致符号解析失败这个是在链接期报错但在动态库的场景里常见于两个.so互相依赖循环依赖没有处理干净。第二个是库版本不匹配编译的时候链接的是高版本的库运行的时候系统里只有低版本低版本里没有这个符号。第三个是符号被隐藏了比如用-fvisibilityhidden编译库但没有显式导出符号。排查手段主要是用nm -D查看动态库的导出符号表objdump -T也可以。先在报错的库里查一遍nm -D libxxx.so | grep symbol_name如果找不到就去它的依赖项里逐个查直到定位到真正缺少符号的库。处理技巧上如果是循环依赖链接时用-Wl,--start-group和-Wl,--end-group包住库列表如果是符号隐藏检查代码里的导出宏是否设置正确。5.3 版本冲突动态链接的版本冲突是生产环境的高频故障典型报错长这样/lib64/libc.so.6: version GLIBC_2.34 not found (required by ./app)GLIBC 有符号版本机制新版本的库会带版本号导出符号老版本库没有这些版本就无法满足要求。检查方法是用strings看看系统里实际 GLIBC 支持的版本strings /lib64/libc.so.6 | grep GLIBC_对比一下报错里要求的版本是否在列表中。这类问题的坑在于编译环境的 GLIBC 比运行环境新太多解决的根本办法是让编译环境与运行环境匹配。临时缓解可以用patchelf修改 ELF 里的依赖版本记录但这是下下策容易引入更大的兼容性问题不推荐。更靠谱的做法是使用容器或者旧系统镜像来编译保证二进制和运行环境一致。5.4 符号被“截胡”还有一种隐蔽的坑叫符号插桩也叫全局符号覆盖。动态链接器解析符号的时候有一个规则如果一个符号在可执行文件本身里有定义那么共享库里的同名全局符号会被“忽略”可执行文件里的定义会胜出哪怕它后面才被加载。这就是为什么有人自定义了一个malloc函数链接进程序能“覆盖”掉 libc 的malloc。这可以当作一种调试或干预手段但也会带来莫名其妙的问题。常见的坑是你在程序里定义了一个通用名字的全局函数比如debug恰好某个.so里也有一个debug函数且没有声明static那么.so内部对debug的调用会被劫持到你的函数导致完全无法预料的运行结果。排查这类问题很费劲因为代码看起来完全正常。解决办法是编译库的时候使用-fvisibilityhidden加上显式导出宏只暴露你真正想公开的符号链接可执行文件时用-Wl,-Bsymbolic让共享库优先解析自己的内部符号。平时写库代码养成给内部函数加static的习惯也是规避这个问题的基本功。5.5 排查工具速查表场景首选工具示例命令查看依赖列表lddldd app查看动态段元信息readelfreadelf -d app查看符号表nm / objdumpnm -D libxxx.so查看重定位表readelfreadelf -r libxxx.so跟踪链接过程LD_DEBUGLD_DEBUGall ./app查看库缓存ldconfigldconfig -p配置库搜索路径ldconfigecho /opt/mylib /etc/ld.so.conf.d/mylib.conf ldconfig把这几个命令用熟动态链接相关的问题基本都能用它们定位到自行解决。我自己排查线上问题的时候LD_DEBUG是压箱底的杀手锏虽然输出量大但它能明确告诉你符号是从哪里解析的、路径是在哪一步断掉的信息量和效率远超猜来猜去。最后再分享一个实操层面的小技巧。很多人改完LD_LIBRARY_PATH发现不生效就一脸懵先确认你是不是用sudo执行的——sudo默认会重置环境变量。再看有没有 setuid 标志。排除了这些之后就用LD_DEBUGlibs跑一下动态链接器会老老实实把每一步搜索路径打印出来问题出在哪一目了然。搞懂动态链接不是让你背概念而是让你在报错面前能冷静下来顺着机制一层层拆解最后找到解药。
动态链接核心机制解析：PIC、GOT/PLT与延迟绑定实战
动态链接这事儿说大不大说小不小。我见过不少人编译个 C 程序报undefined reference会解决一到了运行时报error while loading shared libraries就抓瞎更别提让他解释PLT、GOT、延迟绑定这些词到底在干什么。其实动态链接就是程序从源码变成进程的最后一个关键环节搞懂它很多莫名其妙的运行时报错你一眼就能看穿。这篇文章我打算从“为什么需要动态链接”开始讲把地址无关代码、GOT/PLT、动态链接器的工作流程、搜索路径全部拆开揉碎最后带你自己动手做一遍实验亲自观察一次动态链接的完整过程。适合 C/C 开发者、对系统底层好奇的运维同学以及所有被链接错误折磨过的人。我尽量说人话但底层机制该讲透的地方绝不绕弯子。1. 动态链接到底解决什么问题1.1 从静态链接说起要理解动态链接必须先知道静态链接是怎么回事。早期程序开发基本就是静态链接你写了一个main.c调用了一个printf编译链接的时候链接器会把printf的机器码从libc.a这个静态库里直接拷贝一份塞进你的可执行文件里。最后生成的可执行文件是自包含的拿到任何一台同架构的 Linux 机器上都能跑这是它最大的优点。但缺点很致命假如系统里有 100 个程序都调用了printf那么磁盘上就有 100 份printf的机器码副本。这还只是磁盘占用的问题更麻烦的是内存。每个程序运行的时候这 100 份printf会被各自加载到内存里物理内存中就存了 100 份一模一样的代码。按现在动辄几百 MB 的库来算这种浪费是难以接受的。另外还有一个维护性的问题。如果printf内部发现了一个安全漏洞需要修复静态链接的世界里你没有任何办法——除非把系统里所有依赖这个函数的程序全部重新编译一遍再重新分发。这在一个大型系统里几乎是不可能完成的任务。1.2 动态链接的设计思路动态链接的思路完全反过来了。可执行文件里不再存放库函数的机器码只存放一个“引用说明”——告诉系统我这个程序需要用到哪个共享库里的哪个符号。真正的代码留在.so文件里程序运行之前由系统里一个叫做动态链接器的程序去找到这些.so把它们加载进内存再把可执行文件里的引用和库里的实际地址关联起来。这个方案带来的好处是肉眼可见的。第一磁盘和内存都省了100 个程序共享一份libc.so物理内存里只放一份.text段大家通过页表映射共享它内存占用从 100 份变成 1 份加一些私有的数据段。第二升级变得无比简单修复了libc.so的漏洞直接替换这个.so文件重启依赖它的程序就生效了不需要重新编译任何业务代码。不过别高兴太早动态链接不是免费的午餐。它引入了新的运行时开销——程序启动时动态链接器要干活符号的解析也需要时间它引入了新的失败模式——运行时报“找不到 .so”、报“undefined symbol”这些都是静态链接时代不存在的错误。你写代码的时候编译通过了不代表程序就能跑起来这就是动态链接给所有开发者的“惊喜”。1.3 两种链接方式的对比维度静态链接动态链接可执行文件大小大包含全部依赖代码小只包含引用信息内存占用每个进程各存一份共享库物理内存共用一份启动速度快直接运行慢需要动态链接器解析升级维护需要重新编译所有依赖者替换 .so 即可兼容性风险低自包含高依赖系统库版本部署便利性拷贝即用需要带上所有依赖库从这张表能看出来动态链接不是在所有场景都优于静态链接。做嵌入式开发、做容器镜像的朋友经常会有意识地使用静态链接就是为了避免动态库依赖带来的部署噩梦。理解了这个背景再看后面的机制就顺理成章了。2. 动态链接的三大核心机制2.1 地址无关代码PIC动态链接面临一个根本性的问题.so文件在被加载进内存的时候加载地址是不确定的。同一个.so在进程 A 里可能被加载到0x7f0000000000在进程 B 里可能被加载到0x7f1111111000。如果代码里面直接写了绝对地址那这个.so只能被加载到固定位置否则一运行就崩。解决办法就是编译时加-fPIC。PIC 是 Position Independent Code 的缩写它的核心思想是代码段里不直接引用绝对地址所有对全局变量和函数的访问都通过一个间接层——全局偏移表GOT来完成。代码里存的只是一个“偏移量”程序加载后动态链接器算出.so的真实基地址再把这个基地址加上偏移量填充进 GOT代码通过 GOT 间接访问数据就和加载地址无关了。你会问为什么链接器不直接修改代码里的地址因为代码段在进程间是共享的如果每个进程都要修改代码段里的地址就破坏了共享性必须为每个进程复制一份私有的代码段副本。而 GOT 是数据段每个进程可以有自己的一份修改 GOT 不影响共享的代码段。这就是“地址无关”的精髓——共享代码私有数据。2.2 GOT 与 PLT 的分工很多人把 GOT 和 PLT 混在一起讲其实它们分工完全不同。GOT 是全局偏移表它存放的是地址数据全局变量的地址、函数的真实地址。而 PLT 是过程链接表它存放的是一小段跳转指令是给函数调用准备的“跳板”。简单梳理一下函数调用的路径。你写的代码调用add(1, 2)编译后生成的指令是call addplt。addplt是 PLT 里的一项它的内容大致是先跳转到 GOT 里记录的地址如果 GOT 里还没填上add的真实地址就触发动态链接器去解析解析完再填回 GOT如果已经填过了就直接跳到目标函数。这个设计精妙在它把“调用函数”这个行为统一变成了“查 GOT”而 GOT 的内容是运行时才确定的完美配合 PIC 方案。为什么要把全局变量和函数分开处理因为两者的访问模式不同。全局变量是直接读数据编译器会把对全局变量的访问编译成通过 GOT 间接寻址的指令比如mov rax, [rip GOT_offset]。函数则是通过 PLT 跳板加一层间接跳转。实际调试的时候你用objdump -d看一个动态链接的可执行文件会看到大量plt结尾的调用指令那就是在走 PLT 这条路径。2.3 延迟绑定如果程序一启动就把所有依赖库里的所有函数都解析好那启动速度会慢得吓人。实际上很多程序用到的库函数只占库导出函数的一小部分比如一个程序可能只用了libc.so里的 20 个函数而 libc 导出了几千个符号。全部解析明显不划算。于是出现了延迟绑定也叫懒绑定。它的思路是函数第一次被调用的时候才去解析真实地址后面再调用就直接命中。实现方式就是 PLT 和 GOT 配合——GOT 里初始存放的是 PLT 下一行指令的地址而不是真实函数的地址。第一次调用的时候程序会跳到 PLTPLT 跳到 GOT发现 GOT 里存的是 PLT 下一条指令于是相当于跳到了 PLT 里的解析代码由它把真实地址解析出来并写回 GOT然后再跳转到真实函数。第二次调用GOT 里已经是真实地址了一条指令就直接过去了。你可以用环境变量LD_BIND_NOW1来关闭延迟绑定让动态链接器在程序启动的时候就把所有符号解析完。这通常用于安全敏感的场景因为延迟绑定意味着 GOT 在运行期会被写入如果程序有漏洞攻击者可能利用 GOT 覆写来劫持控制流。后面的实验部分我会带你亲眼观察这个由“未解析”到“已解析”的变化。3. 动态链接器的工作流程与搜索路径3.1 编译阶段写入了什么动态链接不是运行时的独角戏它从编译阶段就开始准备了。当你执行gcc -fPIC -shared -o libfoo.so foo.c的时候编译器和链接器会生成一个特殊的 ELF 文件里面包含一个动态段记录了各种元信息。你可以用readelf -d查看这个动态段。里面会有NEEDED条目标明这个.so依赖哪些其他库有SONAME条目相当于这个库的“身份证名字”程序记录依赖时记的是 SONAME 而不是文件名这样文件名改了只要 SONAME 不变程序照样能找到它可执行文件里还会有RPATH或RUNPATH预先指定搜索库的路径。还有一个容易被忽略的东西叫作.interp段。它记录了动态链接器本身的路径在 Linux 上一般是/lib64/ld-linux-x86-64.so.2。内核加载可执行文件的时候会先读这个段找到动态链接器把它也加载进进程然后把控制权交给它而不是直接交给程序的入口函数。这也就是说动态链接的程序真正意义上的“第一个执行者”是动态链接器。3.2 加载阶段动态链接器做了什么动态链接器的工作可以分成几步。第一步它要先把自己“安顿好”——因为动态链接器本身也依赖一些库这有个鸡生蛋的问题动态链接器在编译时使用了特殊技巧它内部的依赖在加载的第一步就要手工处理好这部分非常底层一般开发者不用深究。第二步它读取可执行文件的动态段找出所有NEEDED条目逐一把依赖的共享库加载进内存。库本身又有自己的依赖所以这是一个递归的过程最终构建出一张完整的依赖图。加载库的过程就涉及路径搜索。第三步就是重定位和符号解析。动态链接器遍历每个库和可执行文件的重定位表根据符号表找到每个符号的真实地址然后填充 GOT 和其他需要修正的位置。这一步是最耗时的。做完这些之后它才调用每个库的初始化函数最后跳转到程序的入口_start程序正式开始执行。3.3 搜索路径的顺序动态链接器查找共享库的路径有一套明确的顺序搞懂这个顺序大部分“找不到库”的问题都能自己解决。我按优先级从高到低列出来DT_RPATH可执行文件动态段里记录的绝对路径已废弃不推荐使用。LD_LIBRARY_PATH环境变量指定的路径列表。DT_RUNPATH可执行文件动态段里记录的路径优先级比LD_LIBRARY_PATH低。/etc/ld.so.cache这是ldconfig生成的缓存文件记录了系统已知的共享库位置。默认目录一般是/lib、/usr/lib64 位系统还有/lib64、/usr/lib64。有一个很关键且容易被忽略的规则DT_RPATH只在它自身存在时生效而且它的优先级高于LD_LIBRARY_PATH而DT_RUNPATH是在链接时用-Wl,-rpath加的新机制它只影响它所在这个库或可执行文件的依赖查找不影响库的依赖。所以如果你在可执行文件上设了DT_RUNPATH它的依赖库再去查找自己的依赖时DT_RUNPATH不会传递给下一级这时候还是得靠LD_LIBRARY_PATH或者系统缓存。注意LD_LIBRARY_PATH在 setuid 和 setgid 的程序上会被内核和动态链接器直接忽略因为环境变量太容易被利用了。遇到 suid 程序报找不到库别想着靠环境变量解决要么装到系统目录要么重新编译指定 RUNPATH。4. 实操亲手观察一次动态链接4.1 准备实验文件理论讲再多不如自己跑一遍。我这里准备两个文件一个共享库一个可执行程序// libmath.c #include stdio.h int add(int a, int b) { int result a b; printf(add called, result %d\n, result); return result; }// main.c #include stdio.h extern int add(int a, int b); int main() { int sum add(3, 4); printf(sum %d\n, sum); return 0; }这个例子足够简单但完整覆盖了函数调用、全局变量访问打印、标准库依赖这些动态链接的核心场景。先编译共享库再编译可执行程序gcc -fPIC -shared -o libmath.so libmath.c gcc -o app main.c -L. -lmath注意第二行命令里的-L.是告诉编译期的链接器在当前目录找libmath.so-lmath是链接libmath.so的缩写形式。不加-L.的话库在默认搜索路径里找不到编译就会报错。4.2 读取 ELF 信息先用readelf看看可执行文件的动态段readelf -d app | grep -E NEEDED|RPATH|RUNPATH正常情况下你会看到类似这样的输出0x0000000000000001 (NEEDED) 共享库[libmath.so] 0x0000000000000001 (NEEDED) 共享库[libc.so.6]这说明app的动态段里只是记录了依赖关系并没有包含add函数的任何代码。再看一下.interp段readelf -l app | grep INTERP输出会显示动态链接器的路径比如/lib64/ld-linux-x86-64.so.2。这个路径就是内核加载完app之后要去加载的动态链接器的位置。4.3 观察 PLT 和 GOT用objdump -d反汇编app重点看main函数和 PLT 段objdump -d app | grep -A 20 main:你会看到对add的调用不是call add 的地址而是call 401030 addplt。跳到了 PLT 段。再单独看 PLTobjdump -d app | grep -A 10 addplt:输出大致是这样0000000000401030 addplt: 401030: ff 25 e2 2f 00 00 jmp *0x2fe2(%rip) # 404018 addplt0x18 401036: 68 00 00 00 00 push $0x0 40103b: e9 e0 ff ff ff jmp 401020 addplt0xfffffffffffffff0这段就是延迟绑定的入口。第一行跳转到 GOT 里记录的地址注释里的404018就是这个函数的 GOT 条目地址。第一次执行的时候GOT 里存的是下一条指令的地址401036于是跳回来执行push $0x0——这个 0 是符号在重定位表里的序号——然后跳到 PLT 的第一条统一入口动态链接器根据序号去解析add的真实地址写回 GOT。4.4 用 LD_DEBUG 观察运行时的解析过程GLIBC 的动态链接器内置了一个调试开关LD_DEBUG能打印出内部的每一个步骤。这是理解动态链接最直观的工具。先看libs查看库的加载顺序LD_DEBUGlibs ./app输出会列出app依赖的libmath.so、libc.so.6等被依次加载的过程包括它们最终被映射到的内存地址。再看bindings观察符号是怎么绑定的LD_DEBUGbindings ./app你会看到add这个符号在第一次被调用时完成绑定。还有个reloc选项可以观察重定位的细节LD_DEBUGreloc ./app输出量很大但你能看到动态链接器逐条处理重定位表项把符号地址写入 GOT 的全过程。我建议你实际敲一遍这些命令输出比任何文字都更有说服力。LD_DEBUG还支持help参数列出所有可用选项适合自己玩。4.5 搜索路径实验现在做一个小实验把libmath.so从当前目录移走再运行appmv libmath.so /tmp/ ./app你会得到经典的报错./app: error while loading shared libraries: libmath.so: cannot open shared object file: No such file or directory然后试试用环境变量救回来LD_LIBRARY_PATH/tmp ./app程序又能跑了。这就是LD_LIBRARY_PATH发挥作用的过程。但如果我重新编译把路径写死进程序里gcc -o app main.c -L. -lmath -Wl,-rpath,/tmp ./app再把/tmp/libmath.so删掉程序照样报错。-Wl,-rpath路径虽然印在了 ELF 里但库里没有就是没有搜索路径再正确也找不到文件。如果把库放进默认搜索目录/usr/lib或者/usr/local/lib然后运行ldconfig更新缓存即使不设置环境变量程序也能找到这就是生产环境最常见的部署方式。5. 常见问题与排查技巧5.1 找不到共享库这是动态链接最常见的问题报错长得都一样./app: error while loading shared libraries: libxxx.so: cannot open shared object file: No such file or directory排查思路分三步走。第一步用ldd app看所有依赖的库哪些找不到输出里带“not found”字样的就是问题所在。第二步确定这个库在系统里到底有没有用find / -name libxxx.so*全局搜一下。第三步如果库确实存在但没在默认搜索路径里有三种解法临时调试用LD_LIBRARY_PATH长期使用用ldconfig 配置文件打包部署用-Wl,-rpath把相对路径比如$ORIGIN/lib写进 ELF。提示ldd本身不是万能的它会调用动态链接器来解析依赖。如果一个库是为不同架构编译的ldd可能报错或者输出一些奇怪的提示这时候用readelf -d配合readelf -h检查架构更可靠。5.2 undefined symbol 的错误运行时报undefined symbol: xxx比找不到库更难排查因为它意味着库文件找到了但某个符号在它的依赖项里找不到定义。常见原因有三个第一个是链接顺序问题使用静态库时顺序不对会导致符号解析失败这个是在链接期报错但在动态库的场景里常见于两个.so互相依赖循环依赖没有处理干净。第二个是库版本不匹配编译的时候链接的是高版本的库运行的时候系统里只有低版本低版本里没有这个符号。第三个是符号被隐藏了比如用-fvisibilityhidden编译库但没有显式导出符号。排查手段主要是用nm -D查看动态库的导出符号表objdump -T也可以。先在报错的库里查一遍nm -D libxxx.so | grep symbol_name如果找不到就去它的依赖项里逐个查直到定位到真正缺少符号的库。处理技巧上如果是循环依赖链接时用-Wl,--start-group和-Wl,--end-group包住库列表如果是符号隐藏检查代码里的导出宏是否设置正确。5.3 版本冲突动态链接的版本冲突是生产环境的高频故障典型报错长这样/lib64/libc.so.6: version GLIBC_2.34 not found (required by ./app)GLIBC 有符号版本机制新版本的库会带版本号导出符号老版本库没有这些版本就无法满足要求。检查方法是用strings看看系统里实际 GLIBC 支持的版本strings /lib64/libc.so.6 | grep GLIBC_对比一下报错里要求的版本是否在列表中。这类问题的坑在于编译环境的 GLIBC 比运行环境新太多解决的根本办法是让编译环境与运行环境匹配。临时缓解可以用patchelf修改 ELF 里的依赖版本记录但这是下下策容易引入更大的兼容性问题不推荐。更靠谱的做法是使用容器或者旧系统镜像来编译保证二进制和运行环境一致。5.4 符号被“截胡”还有一种隐蔽的坑叫符号插桩也叫全局符号覆盖。动态链接器解析符号的时候有一个规则如果一个符号在可执行文件本身里有定义那么共享库里的同名全局符号会被“忽略”可执行文件里的定义会胜出哪怕它后面才被加载。这就是为什么有人自定义了一个malloc函数链接进程序能“覆盖”掉 libc 的malloc。这可以当作一种调试或干预手段但也会带来莫名其妙的问题。常见的坑是你在程序里定义了一个通用名字的全局函数比如debug恰好某个.so里也有一个debug函数且没有声明static那么.so内部对debug的调用会被劫持到你的函数导致完全无法预料的运行结果。排查这类问题很费劲因为代码看起来完全正常。解决办法是编译库的时候使用-fvisibilityhidden加上显式导出宏只暴露你真正想公开的符号链接可执行文件时用-Wl,-Bsymbolic让共享库优先解析自己的内部符号。平时写库代码养成给内部函数加static的习惯也是规避这个问题的基本功。5.5 排查工具速查表场景首选工具示例命令查看依赖列表lddldd app查看动态段元信息readelfreadelf -d app查看符号表nm / objdumpnm -D libxxx.so查看重定位表readelfreadelf -r libxxx.so跟踪链接过程LD_DEBUGLD_DEBUGall ./app查看库缓存ldconfigldconfig -p配置库搜索路径ldconfigecho /opt/mylib /etc/ld.so.conf.d/mylib.conf ldconfig把这几个命令用熟动态链接相关的问题基本都能用它们定位到自行解决。我自己排查线上问题的时候LD_DEBUG是压箱底的杀手锏虽然输出量大但它能明确告诉你符号是从哪里解析的、路径是在哪一步断掉的信息量和效率远超猜来猜去。最后再分享一个实操层面的小技巧。很多人改完LD_LIBRARY_PATH发现不生效就一脸懵先确认你是不是用sudo执行的——sudo默认会重置环境变量。再看有没有 setuid 标志。排除了这些之后就用LD_DEBUGlibs跑一下动态链接器会老老实实把每一步搜索路径打印出来问题出在哪一目了然。搞懂动态链接不是让你背概念而是让你在报错面前能冷静下来顺着机制一层层拆解最后找到解药。
