1

我有一个可执行文件 A 用于dlopen打开共享库 libB.so （位于同一目录中，所以我执行 LD_LIBRARY_PATH=. 让我的程序正确找到它）。这个库 libB.so 应该在 libC.so 中找到它的一些符号，它也位于同一目录中。

但是，/usr/lib64 中还有一个 libC.so（它已使用不同的参数编译，因此它没有相同的符号），并且由于未知原因，libB.so 尝试打开这个而不是那个那是在同一个目录中。当我做 aldd libB.so我可以看到libC.so => /usr/lib64/libC.so而不是libC.so => /path/to/program/A/libC.so.

有没有办法改变 libB.so 中的这个链接（如果可能的话不重新编译），或者如果我应该重新编译 libB.so，是什么让编译器选择在 /usr/lib64 中使用 libC.so 而不是另一个？

（注意：替换 /usr/lib64 中的 libC.so 不是一个选项，因为我不是平台的管理员）

谢谢

4

2 回答 2

0

我弄清楚了问题所在：我在超级计算机上运行，​​当然在程序实际运行之前，有些事情是在后台使用环境变量完成的。这弄乱了我的共享库。

于 2012-07-31T16:24:55.060 回答
0

如果我正确理解了手册页，则 LD_LIBRARY_PATH 应该取代系统范围的路径，例如/usr/lib64，所以我不确定为什么这不起作用。

它是一个 setuid / setgid 程序吗？LD_LIBRARY_PATH 被忽略。

当前路径 ( .) 是否正在发生变化，以至于LD_LIBRARY_PATH=.不再让 libB 找到 libC？

通过strace运行程序应该可以让您看到 ldd 正在检查 libC 的目录；这可能会帮助您调试搜索的位置和方式。

于 2012-07-31T16:13:42.817 回答