从相对于加载可执行文件的目录加载.soso

由于各种原因主要与惯性有关，因此我们没有make install目标。从相对于加载可执行文件的目录加载.soso

相反，我们将我们的大型C++代码库直接构建到类似FHS的树中;

output/ 
    bin/ 
    lib/ 
    etc/ 
    ...

我们最近更换了一些第三方的库来动态链接，所以我们推了一些.so库到lib/。

现在，我们习惯于能够从bin/启动我们的可执行文件，但由于加载程序不能搜索我们的lib/目录，因此不再有效。

LD_LIBRARY_PATH可以解决这个问题，但我们不希望在每个可执行文件调用之前提供它，而且我们也不想将它粘贴到shell的环境中，因为我们通常在多个不同的构建树在同一个shell中。

我们已经考虑在生成的ELF中添加一个rpath条目，但相对路径通常是针对$PWD解析的，而不是可执行文件的dirname。

有没有办法让装载程序在dirname(argv[0])/../lib中查找.so库文件？基本上，我知道有很多方法可以改变我们的习惯来完成这项工作（也许应该），但是我们不希望在这一点上，所以我们可以强制Linux这么装载机来做我们的工作想？谢谢！

来源

2015-10-13 Kim Gräsman

是的，可以使用rpath和${ORIGIN}宏，它在运行时被ld.so识别。

从man ld.so：

ld.so understands certain strings in an rpath specification 
(DT_RPATH or DT_RUNPATH); those strings are substituted as follows 

$ORIGIN (or equivalently ${ORIGIN}) 
    This expands to the directory containing the application executable.

更多变量可用。你不需要强加载任何东西。它有你的功能。 :)

来源

2015-10-13 19:14:10 ezaquarii

不错，谢谢！即使没有'rpath'，我不认为有办法实现这一点？ –

Windows有一个清单文件的概念，你放在可执行文件旁边，来控制这样的东西。如果有'ld，so'类似的带外机制，那将是很酷的。 –

最流行的解决方案是提供封装外壳脚本，用于设置环境并调用二进制文件。许多大项目都这样做。 'IntelliJ IDEA'或'Android Studio'是两个值得注意的例子。 – ezaquarii

从相对于加载可执行文件的目录加载.soso

回答

相关问题