在基于 libtool 的项目中使用 -rpath 和 $ORIGIN 吗？
我正在尝试将基于 libtool 的包合并到我自己的项目中，也许是以非标准的方式。这是我的目标：
构建外部项目：
./configure --prefix=$HOME/blah --etcetera &&制作&&进行安装构建我自己的项目，该项目在运行时依赖于外部项目的共享库和可执行文件：
gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program将所有内容打包到单个“本地化”tarball 中...也就是说，虽然我在
$HOME/blah在构建主机上我希望能够将 tarball 提取到任何任意目录（在其他主机上），而不必与我的环境混淆。目的是允许我的项目的多个版本并排共存，而不会出现任何令人讨厌的“异花授粉”。
我知道我可以在我的项目中使用 -rpath '$ORIGIN/../lib' 来确保在运行时始终加载正确的共享库。然而，libtool 似乎坚持根据 $HOME/blah/lib 的确切路径分配自己的 -rpath 设置，如果我碰巧将所有内容解压到不同的目录（例如，$HOME/blah.2011-06-02）。
有办法绕过这个限制吗？我看到 debian 和 libtool 人员之间相当长的 rpath 讨论关于这个话题，但除了“我们不同意”之外，它有点陈旧且不确定。
I am trying to incorporate a libtool-based package into a project of my own, perhaps in a non-standard way. Here is my goal:
Build external project:
./configure --prefix=$HOME/blah --etcetera && make && make installBuild my own project which depends upon the external project's shared libraries and executables at runtime:
gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/programPackage everything into a single "localized" tarball... that is, while I have everything in
$HOME/blahon the build host I want the ability to extract the tarball to any arbitrary directory (on some other host) without having to futz with my environment. The intent is to allow multiple versions of my project to coexist side-by-side without any nasty "cross-pollination".
I know that I can use -rpath '$ORIGIN/../lib' for my project to ensure that the right shared libraries always get loaded at runtime. However, it seems that libtool insists on assigning its own -rpath setting based on the exact path of $HOME/blah/lib, which breaks if I happen to untar everything into a different directory (say, for example, $HOME/blah.2011-06-02).
Is there a way around this limitation? I see a rather lengthy rpath discussion between debian and libtool folks on the topic, but it's somewhat old and inconclusive beyond "we disagree".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 debian Wiki 上的 Rpathissue 上提供的选项中，使用
chrpath在“安装”步骤或某些后处理脚本中听起来像是一个可行的选择。 （它可以通过您最喜欢的包管理器在许多发行版上使用。）它不需要修补
libtool这在我看来是一个优点。请注意，它有一些限制：只能保存新的
rpath如果它比原始路径更短（或长度相同）。另一个（实用的）选项是删除 rpath（chrpath 可以做到这一点），并仅使用一个包装器脚本将 LD_LIBRARY_PATH 设置为应用程序所需的任何内容。这也有可能稍微更便携（如果您处理某些操作系统具有的其他共享库路径环境变量）。
Among the options presented here on Rpathissue on the debian Wiki, using
chrpathin your 'install' step or some post-processing script sounds like a viable option. (It's available on a bunch of distros via your favorite package manager.)It doesn't require patching
libtoolwhich is a plus IMO.Note that it has some limitations: can only save the new
rpathif it's shorter (or same length) as the original one.The other (pragmatic) option is to remove the
rpath(chrpath can do that), and just have a wrapper script that setsLD_LIBRARY_PATHto whatever is necessary for your app. That has a chance of being slightly more portable too (if you handle the other shared library path environment vars some OSes have).