如何找到库依赖项？答案

【问题标题】：How to find library dependency?如何找到库依赖项？
【发布时间】：2017-05-04 14:01:48
【问题描述】：

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

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

我无法弄清楚 libboost_system.so.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

【问题讨论】：

您是如何构建输出库的？你用了什么命令？在问题的最基础上，依赖来自那里。
我在原文中添加了链接命令的简要说明。
"很多目标文件" "很多 -L/wherver -lwhatever 选项" 认真的吗？我们应该怎么处理这种含糊不清的东西哈哈
抱歉含糊不清。有必要。目标文件是 30 个 .o 文件的列表。 -Lwherever -lwhatever 选项就是这样。我对 -L 目录中的所有 .so 文件运行了 ldd 。我不确定如果我提供实际列表是否会有所帮助。它包含大约 60 个文件。
不，没有必要，因为在您构建了minimal reproducible example 之后，您可以给我们一个简单的单行代码来演示问题。作为个人调试工作的一部分，您应该已经这样做了。

标签： c++ boost linker nvcc

【解决方案1】：

此问题并非特定于使用nvcc。链接可执行文件时，将带有-L 标志的第三方库的路径传递给链接器。当您执行ldd 或最终使用您的库的二进制文件时，将调用动态加载程序。 ld.so(8) 手册描述了加载程序在查找库时搜索路径的顺序。在您的情况下，加载程序很可能首先找到 boost 1.36 库，并且仅对于 1.36 版本中不存在的库，它会回退到 1.62 版本。我建议你检查LD_LIBRARY_PATH环境变量中路径的顺序。

另请注意，ldd 是递归的，因此它不会显示 您的库 链接到的库。您可以使用例如lddtree 在this answer 中提到。

【讨论】：

【解决方案2】：

使用objdump -p libABCD.so | grep NEEDED 查看各个库文件的依赖关系。然后继续输出库。

【讨论】：

【解决方案3】：

除了在链接器命令行上将 boost 库指定为 -l 之外，您还可以为它们提供完整路径和文件名。这样，链接器就不会在搜索路径中查找这些库，并且您可以确保系统版本不会被意外拾取。

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

【讨论】：

是的，不要这样做。您最终将库路径硬编码到可执行文件中，并且它变得不可移植。
@BoundaryImposition 根据this question 的第二个和第四个答案，如果一个库有一个名字，那么用它的完整路径而不是 -l 来给它是可以的，我认为提升图书馆有一个别名。
我总是设置 soname，这不是我的经验
@BoundaryImposition 一方面我刚刚检查了它，在我的 Gentoo Linux amd64 系统上，一个带有完整路径的 soname 库在链接器命令行上没有 -l 标志被链接，但没有指定任何路径到可执行文件中的那个库（即 rpath 是空的并且库名称没有任何额外的路径组件）。另一方面，OP 可以随时使用chrpath 稍后删除 rpath。