链接了错误的共享库

Question

我正在尝试链接库的修改版本 (LAME)。

我下载了源代码，进行了修改并构建了共享对象文件。

然后我将共享库文件复制到我想要链接到的项目的./lib 文件夹中。另一个项目只是测试我的修改的一个小工具。我还从 LAME 的 ./include 复制了相关标题。

我建立了我的安全带：

gcc -c  src/harness.c -o obj/harness.o
gcc obj/harness.o -o bin/harness -L./lib/ -libmp3lame

但令我惊讶的是：

$ ldd ./bin/harness
linux-vdso.so.1 =>  (0x00007fffbc5fe000)
libmp3lame.so.0 => /usr/lib/x86_64-linux-gnu/libmp3lame.so.0 (0x00007f10d9468000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f10d90a0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f10d8d9b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f10d9713000)

（链接的是 /usr/lib/... 库，而不是线束项目目录中 ./lib 中的库。

然后我将自定义的 libmp3lame.so 的名称更改为 libsomeothername.so 并尝试链接它。同样的事情发生了 - 安装的 libmp3lame 被链接而不是我自定义的。

这里发生了什么？为什么编译器不按它说的做呢？为什么/usr/lib/.../libmp3lame 会被链接即使没有使用该名称？

Answer 1

我使用LD_DEBUG=all 来查看链接器发生了什么，因为LD_LIBRARY_PATH=... 应该链接到正确的库。

事实证明，链接器正在在那里寻找，但预计会找到libmp3lame.so.0，而不是我在那里的libmp3lame.so。最后用.0 重命名库解决了这个问题。

我现在可以跑了：

LD_LIBRARY_PATH=./lib ./bin/harness

我想要的库是链接的。

LD_DEBUG=all 似乎很有用。

Answer 2

ld-linux.so 库是实际控制在运行时链接到哪个库的库。另一方面，GCC 的 -L 选项只会影响库的编译时搜索路径。

手册页说：

当解析库依赖时，动态链接器首先检查 每个依赖字符串，看看它是否包含斜杠（这可能发生 如果在链接时指定了包含斜杠的库路径名）。 如果找到斜线，则依赖字符串被解释为 （相对或绝对）路径名，并使用该路径名加载库 路径名。

如果没有斜线，则沿着预定义的搜索路径（也在手册页中指定）搜索。

要获得您想要的行为，您有以下选择：

1. 链接时指定库的绝对路径，或者

2. 将 LD_LIBRARY_PATH 设置为指向包含您的库的目录，或者

3. 链接时使用 -rpath 选项以在搜索路径中包含包含您的库的目录（注意，要将链接器选项从 gcc 传递给链接器，请使用 -Wl,--rpath=/my/path