C++ 如何找到库依赖关系？

我在一台没有根访问权限的Linux机器上。这台机器上有Boost 1.36，但我需要更新版本的Boost，所以我安装了本地版本的Boost 1.62。我正在用nvcc链接一些对象文件。该链接还包括大约20个第三方动态库。链接的输出结果是另一个动态库

问题是：如果在输出库上运行'ldd'，它会告诉我该库同时依赖于libboost_system.so.1.36.0和libboost_system.so.1.62.0

我搞不懂libboost_系统是怎么来的，所以.1.36.0就在那里。其他动态库都不依赖libboost_system.so.1.36.0（我在所有库上都运行了ldd）。我如何知道libboost 1.36依赖项来自何处

以下是创建输出库的链接器命令的简要说明：

nvcc --ptxas-options=-v --compiler-options '-fPIC' --shared
lots of object files
lots of -L/wherever -lwhatever options
-o libOutput.so

---

您也可以在链接器命令行中将boost库指定为完整路径和文件名，而不是将它们指定为-l。这样，链接器不会在搜索路径中查找这些库，您可以确保不会意外获取系统版本

---

如果问题仍然存在，我建议测试一个不需要任何BOOST库的最小示例，以查看nvcc是否会拉入一些系统版本的BOOST系统库。

此问题不特定于使用

nvcc

。链接可执行文件时，使用

-L

标志将指向第三方库的路径传递给链接器。当执行

ldd

或最终使用库的二进制文件时，将调用动态加载程序。手册描述了加载程序在查找库时搜索路径的顺序。在您的情况下，加载程序很可能首先找到boost 1.36 libs，并且仅对于1.36版本中不存在的libs，它会返回到1.62版本。我建议您检查

LD\u LIBRARY\u PATH

环境变量中路径的顺序

---

还要注意，

ldd

是递归的，因此它不会显示库链接到的libs。您可以使用中提到的

lddtree

。

使用

objdump-p libABCD.so | grep NEEDED

查看对单个库文件的依赖关系。然后继续学习输出库

您是如何构建输出库的？你用了什么命令？最基本的问题是，依赖性来自于此。我在原始文本中添加了对link命令的简要描述。“大量的对象文件”“大量的-L/wherver-lwhatever选项”真的吗？我们该怎么处理这样的模糊呢？对不起，这种模糊。这是必要的。对象文件是30.o文件的列表。-Lwherever-lwhatever选项就是这样。我在-L目录中的所有.so文件上运行了ldd。我不确定如果我提供实际的清单是否会有所帮助。它包含大约60个文件。不，这不是必需的，因为在你构建了你的应用程序之后，你可以给我们一个简单的一行程序来演示这个问题。你应该已经做了，作为你个人调试工作的一部分。是的，不要这样做。您最终将库路径硬编码到可执行文件中，它将变得不可移植。@BoundaryPosition根据第二个和第四个答案，如果库有so名称，则使用其完整路径而不是-l就可以了，我认为boost库有一个很好的名字。我总是设置soname，这不是我的名字experience@BoundaryImposition一方面，我只是检查了一下，并且在我的Gentoo Linux amd64系统上，在链接器命令行上带有完整路径且不带-l标志的soname的库被链接，而不在可执行文件中指定指向该库的任何路径（即，rpath为空，库名称不带任何附加路径组件）。另一方面，OP始终可以在以后删除rpath。