4

我正在尝试将基于 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. 将所有内容打包成一个“本地化”压缩包......也就是说，虽然我在$HOME/blah构建主机上拥有所有内容，但我希望能够将压缩包解压缩到任何任意目录（在其他主机上），而不必与我的环境混为一谈。目的是允许我的项目的多个版本并排共存，而不会出现任何令人讨厌的“异花授粉”。

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

有没有办法绕过这个限制？我看到debian 和 libtool 人员之间就该主题进行了相当冗长的 rpath 讨论，但除了“我们不同意”之外，它有些陈旧且不确定。

4

1 回答 1

1

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

它不需要修补libtool，这是一个加号 IMO。

rpath请注意，它有一些限制：如果它比原来的更短（或相同的长度），只能保存新的。

另一个（实用的）选项是删除rpath（chrpath 可以做到这一点），并且只需有一个包装脚本设置LD_LIBRARY_PATH为您的应用程序所需的任何内容。这也有可能更便于移植（如果您处理某些操作系统具有的其他共享库路径环境变量）。

于 2011-06-03T06:04:46.030 回答