在基于libtool的项目中使用-rpath和$ ORIGIN? [英] Using -rpath and $ORIGIN with libtool-based projects?

问题描述

我试图以一种非标准的方式将基于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)，则会中断. >

有没有办法解决这个限制?我看到了 debian和libtool族之间相当漫长的rpath讨论关于该主题，但是除了我们不同意"之外，它还有些陈旧和不确定.

解决方案

在 Rpathissue 在debian Wiki上，在安装"步骤或某些后期处理中使用 chrpath 脚本听起来像是一个可行的选择. (可以通过您最喜欢的包管理器在许多发行版中找到它.)

它不需要修补libtool，这是一个附加的IMO.

请注意，它有一些局限性:只有新的rpath比原始的短(或相同长度)时，才能保存.

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

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:

1. Build external project:

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

2. Build 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/program
   

3. Package everything into a single "localized" tarball... that is, while I have everything in $HOME/blah on 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".

解决方案

Among the options presented here on Rpathissue on the debian Wiki, using chrpath in 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 libtool which is a plus IMO.

Note that it has some limitations: can only save the new rpath if 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 sets LD_LIBRARY_PATH to 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).

这篇关于在基于libtool的项目中使用-rpath和$ ORIGIN?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！