将 -rpath 和 $ORIGIN 用于基于 libtool 的项目

Using -rpath and $ORIGIN with libtool-based projects?

本文关键字：libtool 项目 用于 -rpath ORIGIN      更新时间：2023-10-16

我正在尝试将基于 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 似乎坚持根据 $HOME/blah/lib 的确切路径分配自己的-rpath设置，如果我碰巧将所有内容解压缩到不同的目录(例如，$HOME/blah.2011-06-02(，则会中断。

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

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

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

请注意，它有一些限制：仅当新rpath与原始更短(或长度相同(时，才能保存新。

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

相关文章：