Question

我的目标是让二进制文件作为安装过程的一部分在另一个系统上工作，即使这些库不在链接器在原始系统上找到它们的位置。

例如：我有一个二进制'程序'，它链接了几个共享库'library1.so'，'library2.so'和'library3.so'。

使用ldd我可以看到libary3.so即使在/ usr / local / lib中也找不到：

$ ldd program
        library1.so.1 => (0x00007fff26ffe000)
        library2.so.10 => /usr/local/lib/library2.so.10 (0x00007fa67087d000)
        library3.so => not found

奇怪的是，其他lib'list2.so'恰好位于'library3.so'所在的位置。

当然我可以使用LD_LIBRARY_PATH修复此问题，但我想避免这种情况。

问题：我还有哪些其他选项来修复丢失的库？

编辑2：我有found this suggestion

处理LD_LIBRARY_PATH的规范规则

永远不要全局设置LD_LIBRARY_PATH。
如果您必须发送使用共享库的二进制文件并希望允许客户在“标准”位置之外安装程序，请执行以下操作之一：
- 将您的二进制文件作为.o文件发送，并作为安装过程的一部分，使用正确的安装库路径重新链接它们。
- 使用非常长的“虚拟”运行时库路径发送可执行文件，并且作为安装过程的一部分，使用二进制编辑器替换可执行文件中的正确安装库路径。
如果您被迫设置LD_LIBRARY_PATH，请仅将其作为包装器的一部分。

子问题：如何使用二进制编辑器更改库路径？

Answer 1

我认为编辑二进制文件以改变路径是个坏主意。尝试包含选项

-Wl,-Bstatic -lstdc++

在链接过程中。在这种情况下，您将具有将在不同系统上调用的静态链接二进制文件。

Answer 2

我找到了patchELF，这就是我需要的：

[...]同样，您可以更改RPATH，即嵌入的链接器搜索路径到可执行文件和动态库：

patchelf --set-rpath /opt/my-libs/lib:/foo/lib program

这会导致动态链接器在/ opt / my-libs / lib中搜索 / foo / lib用于程序所需的共享库。当然，你也可以设置环境变量LD_LIBRARY_PATH，但那是通常不方便，因为它需要一个包装脚本来设置环境。

通过编辑可执行文件

2 个答案: