如何防止 libtool 将系统路径（即 /usr/lib）添加到 RUNPATH（rpath）？

Question

如何防止libtool添加系统路径（即/usr/lib）到RUNPATH（rpath）？

在测试（检查）期间，MPFR libtool 在测试路径之前将系统路径添加到 rpath，即：

0x0000000000000001d (RUNPATH) 库运行路径：[/usr/lib:/LFSC/native/src/bmpfr/src/.libs]

因此，测试可以运行已安装的库（在第一个路径（系统）中）而不是测试库。这通常发生在重新安装软件时。也许这会影响安装升级。

这是因为现有依赖项的 .la 文件，例如libquadmath.la

删除 .la 文件可解决此问题。

但是根本没有理由将系统路径添加到硬编码的 RUNPATH 中。

有什么方法可以在不删除 .la 文件的情况下解决此问题？ 当然我知道我可以更改生成的 libtool 脚本。

---

这是关于 ELF 文件中的硬编码运行路径，它对系统路径和 LD_LIBRARY_PATH 具有高优先级。您可以通过从源代码编译 MPFR 而无需安装来轻松理解这一点。在make check 之后在源文件夹根目录中运行： readelf -a tests/tversion | grep PATH 您将看到没有系统路径的 RPATH。 然后将 libquadmath.la 添加到 gcc lib home 中，例如/usr/lib/gcc/x86_64-linux-gnu/6/ 删除测试并再次检查，然后再次检查tversion中的PATH

# libquadmath.la - a libtool library file
# Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libquadmath.so.0'

# Names of this library.
library_names='libquadmath.so.0.0.0 libquadmath.so.0 libquadmath.so'

# The name of the static archive.
old_library='libquadmath.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=' -lm'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libquadmath.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/lib/../lib'

Answer 1

但是根本没有理由将系统路径添加到硬编码的 RUNPATH 中。

并非如此。大多数系统的默认库搜索路径中有多个目录，实际上搜索路径有时会在安装或删除软件时发生变化。将给定系统库在链接时实际位于的目录（-ies）放入给定二进制文件的 RUNPATH 中，使该二进制文件更能抵抗在运行时动态链接其他同名库。它还可以稍微加快动态链接。

此外，二进制文件的 RUNPATH 在动态链接期间的优先级低于LD_LIBRARY_PATH 环境变量，因此您可以在运行时覆盖RUNPATH，例如您所描述的情况。这就是除了RPATH 之外还有RUNPATH 的全部意义，LD_LIBRARY_PATH 的优先级更高。

在测试（检查）期间，MPFR libtool 将系统路径添加到 rpath 在测试路径之前，即：

0x000000000000001d (RUNPATH) 库运行路径： [/usr/lib:/LFSC/native/src/bmpfr/src/.libs]

我猜你的意思是构建系统将这些条目放入构建树中构建的程序和库中。 Libtool 通常在以（重新）安装模式（部分依赖于 .la 文件）运行时修改运行路径条目。一旦在系统上正确安装了程序或库，就不会期望在其运行路径中看到构建树目录。

另请注意，这是RUNPATH，而不是RPATH。如上所述，这些不是一回事。

因此，测试可以运行已安装的库（在第一个路径（系统）中） 而不是测试。通常在重新安装时会发生这种情况 软件。也许这会影响安装升级。

如果在您运行make check 或通过libtool 在“执行”模式下运行程序时发生这种情况，那么您应该提出针对MPFR 的问题。如果仅在您直接运行已卸载的测试程序时发生这种情况，这不是问题（但另见下文）。

有什么方法可以在不删除 .la 文件的情况下解决此问题？

一般来说，应该期望适当地设置LD_LIBRARY_PATH 以运行已卸载的程序或动态链接到已卸载的库。 make check 应该自动采取适当的措施，并且在使用 libtool 的构建系统中，这可能会采取通过 libtool 运行二进制文件的形式。通常，基于 Autotools 的构建系统实际上会为构建的二进制文件创建包装脚本，以使其尽可能透明。

话虽如此，删除.la 文件不一定是不合理的。 Libtool 有充分的理由创建它们，但是将它们与库本身一起安装到系统中的剩余好处可能无法平衡缺点。一方面，RedHat 长期以来一直认为它不这样做，因此它实际上并没有在其 RPM 包中包含 .la 文件，并且它的打包指南规定第三方打包者也不应该这样做。

最终，如果您想保持外部 .la 文件不被修改，但避免 libtool 在链接时从中提取 RUNPATH 条目，那么您的主要选择是修改项目的 libtool 脚本。细节很大程度上取决于项目使用的 libtool 版本。