22、库依赖问题：ldd与LD_PRELOAD调试技巧

动态链接库的问题，说实话，是嵌入式开发里最让人头疼的坑之一。你编译通过了，链接也过了，结果一运行就报错——"cannot open shared object file"。我刚开始做嵌入式Linux开发那会儿，这种错误至少浪费了我三天时间。后来我才明白，库依赖问题其实有很成熟的调试工具，只是很多人不知道或者懒得用。

22.1 动态链接库的依赖关系

先说说动态链接库是怎么工作的。你的程序在编译时，链接器只记录了它需要哪些库，以及库里的哪些函数。真正把库加载到内存，是在程序启动时由动态链接器完成的。这个动态链接器，在Linux上就是ld-linux.so。

动态链接器会按照一定的顺序搜索库文件：

  1. LD_LIBRARY_PATH环境变量指定的路径
  2. /etc/ld.so.cache中缓存的路径
  3. 默认系统库路径，比如/lib、/usr/lib

嗯，这里要注意：LD_LIBRARY_PATH的优先级最高。我在项目中遇到过，有人把旧版本的库放在这个路径下，结果新版本怎么都加载不上，排查了半天才发现是环境变量在作怪。

22.2 ldd：查看库依赖的利器

ldd命令，全称是"list dynamic dependencies"。它的用法非常简单：

ldd your_program

输出结果大概长这样：

linux-vdso.so.1 (0x00007ffd3b5f0000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3c8a200000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c89e00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3c8a600000)

每一行左边是库名，右边是实际加载的路径。如果某个库找不到，你会看到：

libfoo.so => not found

我个人习惯，拿到一个可执行文件后，第一件事就是跑一下ldd。这能帮你快速判断目标板上的库环境是否完整。比如交叉编译的程序，放到开发板上跑不起来，ldd一看，缺了某个库，那就直接补上就行。

注意：ldd 实际上会尝试加载这些库，所以不要在不可信的二进制文件上使用 ldd。有安全风险。替代方案是用 objdump -p your_program | grep NEEDED，它只读取文件头，不加载库。

22.3 LD_PRELOAD：劫持库函数的黑科技

LD_PRELOAD是个环境变量，它允许你在程序启动时，优先加载你指定的共享库。说白了，就是你可以用自己的函数，替换掉系统库里的同名函数。

这个技巧在调试时特别有用。举个例子，你想追踪程序调用了哪些malloc和free：

// mymalloc.c
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdio.h>

void *malloc(size_t size) {
    static void *(*real_malloc)(size_t) = NULL;
    if (!real_malloc) {
        real_malloc = dlsym(RTLD_NEXT, "malloc");
    }
    void *ptr = real_malloc(size);
    printf("malloc(%zu) = %p\n", size, ptr);
    return ptr;
}

void free(void *ptr) {
    static void (*real_free)(void*) = NULL;
    if (!real_free) {
        real_free = dlsym(RTLD_NEXT, "free");
    }
    printf("free(%p)\n", ptr);
    real_free(ptr);
}

编译成共享库：

gcc -shared -fPIC -o mymalloc.so mymalloc.c -ldl

然后运行你的程序：

LD_PRELOAD=./mymalloc.so ./your_program

这样，每次malloc和free被调用，都会打印日志。我曾经用这个技巧，抓到一个内存泄漏的bug——有个模块在循环里不断malloc但忘了free，日志一看就明白了。

小技巧：LD_PRELOAD 也可以用来临时修复库的bug。比如某个系统库有段错误，你可以写一个补丁函数，用 LD_PRELOAD 加载，不用重新编译整个系统。

22.4 实战：解决库版本冲突

库版本冲突是嵌入式开发里的常见问题。你的程序依赖libssl.so.1.1，但系统里只有libssl.so.1.0。怎么办？

我建议的排查步骤：

  1. 先用ldd确认具体缺哪个库
  2. 用find / -name "libssl*"看看系统里有哪些版本
  3. 如果目标板上有多个版本，可以用LD_LIBRARY_PATH指定路径
  4. 如果实在没有，考虑静态链接或者自己编译缺失的库

举个例子，你的程序需要libssl.so.1.1，但系统只有libssl.so.1.0：

# 查看当前依赖
ldd your_program | grep ssl

# 创建软链接（不推荐，但临时可用）
ln -s /usr/lib/libssl.so.1.0 /usr/lib/libssl.so.1.1

# 或者用 LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/path/to/your/libs:$LD_LIBRARY_PATH
警告：创建软链接来欺骗动态链接器，可能会导致ABI不兼容，程序运行时崩溃。我建议只在开发板上临时测试用，不要用在产品中。

22.5 知识体系图

下面这张图，总结了库依赖问题的核心调试思路：

库依赖问题调试流程 程序运行报错 第一步：ldd 查看依赖 检查是否有 "not found" 有缺失 全部找到 安装缺失库 LD_LIBRARY_PATH 指定 检查版本兼容性 LD_PRELOAD 劫持调试 问题解决

22.6 避坑指南

我曾经踩过一个坑，说出来你可能不信。有个程序在开发板上跑得好好的，换到另一块板子上就报库找不到。我查了半天，发现两块板子的/etc/ld.so.conf配置不一样。第一块板子把库路径写进了配置文件，第二块没有。

所以，如果你用ldconfig更新了库缓存，记得检查/etc/ld.so.conf是否包含了正确的路径。运行ldconfig -p可以查看当前缓存了哪些库。

核心要点：
  • ldd 是查看库依赖的第一工具，但注意安全风险
  • LD_PRELOAD 可以劫持库函数，用于调试和临时修复
  • 库版本冲突时，优先用 LD_LIBRARY_PATH 指定路径
  • 不要轻易创建软链接欺骗动态链接器
  • 检查 /etc/ld.so.conf 和 ldconfig 缓存

说实话，库依赖问题看着复杂，其实套路就那么几个。你只要掌握了ldd和LD_PRELOAD，再配合LD_LIBRARY_PATH，大部分问题都能搞定。剩下的，就是耐心和细心了。

我的习惯：每次拿到一个新的嵌入式开发板，我都会先跑一遍 ldd /bin/ls，看看系统库环境是否完整。这花不了几分钟，但能避免后面很多莫名其妙的坑。

嗯，库依赖调试就讲到这里。记住，工具是死的，思路是活的。遇到问题别慌，按流程一步步排查，总能找到根因。

← 上一章 📖 返回目录 下一章 →