我正在尝试将基于libtool的包合并到我自己的项目中，可能是以非标准的方式。这是我的目标：
构建外部项目：
./configure --prefix=$HOME/blah --etcetera && make && make install
构建我自己的项目，该项目在运行时依赖于外部项目的共享库和可执行文件：
gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program
将所有内容打包成一个“本地化”的tarball ...也就是说，当我在构建主机上的$HOME/blah中拥有所有内容时，我希望能够将tarball提取到任意目录（在某些目录上）其他主人）没有必要与我的环境。目的是允许我的项目的多个版本并排共存，没有任何令人讨厌的“交叉授粉”。
我知道我可以在项目中使用-rpath '$ORIGIN/../lib'来确保在运行时始终加载正确的共享库。但是，似乎libtool坚持根据-rpath的确切路径分配自己的$HOME/blah/lib设置，如果我碰巧将所有内容解压缩到不同的目录（例如，{{1} }}）。
有没有解决这个限制的方法？我在这个主题上看到rather lengthy rpath discussion between debian and libtool folks，但除了“我们不同意”之外，它有点陈旧和不确定。
答案 0 :(得分：1)
在debian Wiki上Rpathissue上提供的选项中，在“安装”步骤中使用chrpath或某些后期处理脚本听起来像是一个可行的选项。 （它可以通过您最喜欢的包管理器在一堆发行版中找到。）
它不需要修补libtool这是一个加IMO。
请注意，它有一些限制：如果新的rpath比原始rpath更短（或相同），则只能保存。{/ p>
另一个（实用）选项是删除LD_LIBRARY_PATH（chrpath可以做到这一点），只需要一个包装脚本，将{{1}}设置为应用程序所需的任何内容。这也有可能稍微便于移植（如果你处理其他共享库路径环境变量，那么有些操作系统有。）