错误的共享库正在链接。

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选项在搜索路径中包含包含库的目录(NB )。若要将链接器选项从gcc传递到链接器，请使用-Wl,--rpath=/my/path