c++ - 将 -rpath 和 $ORIGIN 与基于 libtool 的项目一起使用？

Question

我正在尝试将基于 libtool 的包合并到我自己的项目中，也许是以一种非标准的方式。这是我的目标:

1. 构建外部项目:

   ./configure --prefix=$HOME/blah --etcetera && make && make install
   

2. 构建我自己的项目，该项目在运行时依赖于外部项目的共享库和可执行文件:

   gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program
   

3. 将所有内容打包到一个“本地化”tarball 中...也就是说，虽然我在构建主机上的 $HOME/blah 中拥有所有内容，但我希望能够将 tarball 提取到任何任意目录(在其他主机上)，而不必与我的环境混为一谈。目的是让我的项目的多个版本并排共存，而不会出现任何讨厌的“异花授粉”。

我知道我可以为我的项目使用 -rpath '$ORIGIN/../lib' 以确保在运行时始终加载正确的共享库。但是，libtool 似乎坚持根据 $HOME/blah/lib 的确切路径分配自己的 -rpath 设置，如果我碰巧将所有内容解压到不同的目录(例如，$HOME/blah.2011-06-02)。

有没有办法绕过这个限制？我看到一个rather lengthy rpath discussion between debian and libtool folks关于这个话题，但除了“我们不同意”之外，它有点陈旧且不确定。

Answer 1

在此处提供的选项中 Rpathissue在 debian Wiki 上，使用 chrpath在您的“安装”步骤或某些后处理脚本中听起来是一个可行的选择。 (它可以通过你最喜欢的包管理器在一堆发行版中获得。)

它不需要修补 libtool，这是 IMO 的优点。

请注意，它有一些限制:如果新的 rpath 比原始路径更短(或相同长度)，则只能保存新的 rpath。

另一个(实用的)选项是删除 rpath(chrpath 可以做到这一点)，只需要一个包装脚本，将 LD_LIBRARY_PATH 设置为您需要的任何内容应用程序。这也有可能稍微更便携(如果您处理某些操作系统具有的其他共享库路径环境)。