忽略 LD_LIBRARY_PATH 并坚持在链接时通过 -rpath 给出的库答案

【问题标题】：Ignore LD_LIBRARY_PATH and stick with library given through -rpath at link time忽略 LD_LIBRARY_PATH 并坚持在链接时通过 -rpath 给出的库
【发布时间】：2010-03-09 10:13:22
【问题描述】：

我坐在一个我无法真正控制的环境中（不只是我，所以基本上，我无法改变环境，否则它对其他人不起作用），我唯一能影响的就是是如何构建二进制文件的。

我的问题是，环境指定了一个 LD_LIBRARY_PATH，其中包含一个与正在使用的编译器不兼容的 libstdc++。我尝试静态编译它，但这对于 g++ 似乎是不可能的（版本 4.2.3，似乎在以后的版本中已经在这个方向上完成了工作，尽管这些版本不可用，-static-libstdc++ 或类似的东西）。

现在我已经开始使用 rpath 将绝对路径名烘焙到可执行文件中（可行，它应该运行的所有机器都是相同的）。不幸的是，LD_LIBRARY_PATH 似乎优先于 rpath（重置 LD_LIBRARY_PATH 确认它能够找到库，但如上所述，将为所有人设置 LD_LIBRARY_PATH，我无法更改）。

有什么方法可以让 rpath 优先于 LD_LIBRARY_PATH，或者我的问题还有其他可能的解决方案吗？请注意，我说的是运行时动态链接，我可以在编译和链接时控制命令行。

谢谢。

【问题讨论】：

标签： g++ dynamic-linking

【解决方案1】：

也许您可以使用一个外壳包装器来修改这个程序的环境？

#!/bin/sh

LD_LIBRARY_PATH="/path/to/your/lib:${LD_LIBRARY_PATH}"
export LD_LIBRARY_PATH
exec /path/to/binary $@

这应该在执行之前重载 LD_LIBRARY_PATH，然后通过 exec 将包装器替换为您的二进制文件。

这会有帮助吗？

【讨论】：

【解决方案2】：

链接到libstdc++.a 绝对是可能的，尽管很棘手。指令here.

我有点怀疑你声称LD_LIBRARY_PATH 优先于“烘焙”DT_RPATH - 至少在 Linux 和（我相信）Solaris 上，LD_LIBRARY_PATH 仅在 @987654328 之后查看@查找失败。

【讨论】：

我看过这篇文章，“伪造”一个没有“.so”文件的目录可能会起作用。我只能更改编译器和命令行（尽管我想我可以将编译器更改为脚本），但我也许可以创建自己的 lib 目录。我会试一试。至于第二部分，这是一个 Solaris 环境，我所做的测试是：ldd binary 从 LD_LIBRARY_PATH 生成库，LD_LIBRARY_PATH= ldd binary 生成烘焙的（非平凡的）库。我不知道这玩意是怎么实现的，我只能告诉你我看到的。
声称在 Solaris 下LD_LIBRARY_PATH 优先于DT_RPATH 是absolutely correct，只要进程不符合secure process 的定义。