我在Linux机器上，我没有root访问权限。这台机器上有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
答案 0 :(得分：0)
此问题并非特定于使用nvcc。链接可执行文件时，将带有-L标志的第3方库的路径传递给链接器。当您执行ldd或最终使用您的库的二进制文件时，将调用动态加载程序。 ld.so(8)手册描述了加载程序在查找库时搜索路径的顺序。在你的情况下，加载器很可能首先找到boost 1.36 libs，并且仅对于1.36版本中不存在的lib，它会回落到1.62版本。我建议您检查LD_LIBRARY_PATH环境变量中路径的顺序。
另请注意ldd是递归的，因此它不会显示您的库所链接的库。你可以用例如this answer中提及的lddtree。
答案 1 :(得分：0)
使用objdump -p libABCD.so | grep NEEDED查看各个库文件的依赖关系。然后继续输出库。
答案 2 :(得分：-1)
您可以在链接器命令行上将boost库作为-l给出，而不是为它们提供完整路径和文件名。这样链接器就不会在搜索路径中查找这些库，并且可以确保不会意外地拾取系统版本。
如果问题仍然存在，我建议测试一个不需要任何BOOST库的最小示例，看看nvcc是否会提取一些系统版本的boost-system库。