Installation 通过编辑可执行文件修复二进制文件中的库位置

我的目标是让二进制文件作为安装过程的一部分在不同的系统上工作，即使lib不在链接器在我的原始系统上找到它们的地方

例如：我有一个二进制“程序”，它链接到几个共享库“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

奇怪的是，另一个库'library2.so'正好位于'library3.so'所在的位置

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

问题：修复丢失的库还需要哪些其他选项

---

编辑2：我有

处理LD_库路径的规范规则

永远不要全局设置LD_LIBRARY_路径

如果必须提供使用共享库的二进制文件，并且希望允许客户端在“标准”位置之外安装程序，请执行以下操作之一：

• 将二进制文件作为.o文件提供，并作为安装过程的一部分，使用正确的安装库路径重新链接它们
• 提供具有非常长的“虚拟”运行时库路径的可执行文件，并且作为安装过程的一部分，使用二进制编辑器替换可执行文件中正确的安装库路径

如果您被迫设置LD_LIBRARY_PATH，请仅作为包装的一部分进行设置

---

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

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

-Wl，-Bstatic-lstdc++

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

我发现，它满足了我的需要：

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

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

---

谢谢你的建议，python问题只是一个例子。我想在不同的系统上安装时解决不同库位置的问题。我改进了这个问题。

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