C++ 链接器在运行时缺少库(SONAME 行为)

Question

我制作了一个程序，它使用两个共享库(我编译的)并且放置如下:

/home_directory_where_I_compile_and_run_everything
-->/lib/libjson_linux-gcc-4.4.6_libmt.so
-->/lib/libre2.so.0

当我编译我的程序时，我将这些库的相对位置传递给链接器，如下所示:

g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/libre2.so.0

它编译得很好，但是当运行程序时它找不到 libre2.so，如果我用 ldd 检查它，会发生以下情况:

....
lib/libjson_linux-gcc-4.4.6_libmt.so (0x00007f62906bc000)
libre2.so.0 => not found
....

显然，它确实承认 libjson 上的路径是相对的，但它不会在 libre2.so.0 上这样做(它修剪所有路径并只留下 libre2.so.0)

谁能告诉我为什么会这样？

还有，有没有办法通过 g++ 参数修改它？

最好的。

* 更新 * 哇，看看这个!我已将 libre2.so.0 的名称更改为 stuff.so，然后尝试像这样进行基本相同的编译:

g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/stuff.so

无论如何它都失败了；它不仅会失败，而且会因为找不到“libre2.so.0”而失败。

为什么？

* 更新#2 *

readelf -d the_program.o 的输出

0x0000000000000001 (NEEDED)             Shared library: [lib/libjson_linux-gcc-4.4.6_libmt.so]
0x0000000000000001 (NEEDED)             Shared library: [libre2.so.0]

现在，如果我可以将 [libre2.so.0] 改为 [lib/libre2.so.0] 就好了。

* 更新#3 *

正如@troubadour 发现的那样:

When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker.

这就是为什么它适用于 libjson.....so 而不是 libre2.so.0。 (libjson .....所以没有 SONAME 的条目)。

我终于找到了我正在寻找的确切问题:

有什么方法可以告诉 gcc 链接器忽略共享库文件上的 SONAME 条目，而是链接到特定文件路径？

Answer 1

我会先回答你问题的第二部分，即为什么重命名 libre2.so.0 没有达到你的预期。

当您运行可执行文件时，您传递给链接器的文件名是无关紧要的(除非您在构建库时未能提供 -soname - 请参阅下面的第二个编辑)。依赖性取自所谓的“soname”。如果您在您的库上运行 readelf 命令，您可以确定它的 soname，例如。

readelf -d libre2.so.0 | grep SONAME

重命名文件没关系。上面命令的结果仍然会给你相同的 soname，因此程序仍然找不到“libre2.so.0”的原因。

至于您问题的原始部分，这完全取决于库是否内置了 RPATH 或 RUNPATH 和/或您的 LD_LIBRARY_PATH 环境变量是。这些是运行时链接器 (ld.so) 将用来查找共享库的内容。尝试

man ld.so

获取更多信息。

由于您自己构建了这些库，您将知道它们是否在最后的链接阶段使用了 -rpath 或 -runpath 选项。或者，再次使用 readelf 例如。

readelf -d libre2.so.0 | grep RPATH
readelf -d libre2.so.0 | grep RUNPATH

我怀疑以上两个命令不会返回任何内容。

我的猜测是您的 LD_LIBRARY_PATH 中有当前目录，这将允许运行时链接器找到 lib/libjson_linux-gcc-4.4.6_libmt.so 但不是 libre2。所以.0。我注意到您在回复我对您的问题的评论时说您的 LD_LIBRARY_PATH 是空的。这很奇怪。

也许您以某种方式在 libjson 的 soname 上获得了前缀“lib/”？即 readelf 命令返回 SONAME

lib/libjson_linux-gcc-4.4.6_libmt.so

不仅仅是

libjson_linux-gcc-4.4.6_libmt.so

此外，通过运行检查程序在 soname 方面需要什么

readelf -d my_progam | grep NEEDED

也许“lib/”前缀在那里是因为你将它传递给 gcc 的方式。如果是这样，那么如果您使用@enobayram 给出的 gcc 命令，那么它将平衡竞争环境，即它也将无法找到 libjson。

首先要确定的不是为什么它没有找到 libre2.so.0，而是它如何设法找到 libjson。如果您尝试从不同的目录运行您的可执行文件，它仍然有效还是现在对于 libjson 也失败了？或者，如果您将 libre2.so.0 复制到您的可执行文件旁边，这会改变什么吗？

编辑

A posting on the Fedora Forum建议Fedora版本的ld.so内置当前目录作为搜索路径。虽然我无法验证这一点，但它可以解释为什么你要选择任何库，因为你的案例中没有 ld.so 使用的所有其他东西。

编辑2

来 self 系统上的 ld 手册页

-soname=name

When creating an ELF shared object, set the internal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker.

Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back- Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

因此，您评论中的理论是正确的。如果在构建库时未明确指定 -soname 则共享对象中不存在 SONAME 并且可执行文件中的 NEEDED 字段仅包含提供给链接器的文件名，在您的情况下，包含领先的“lib/”。