How to prevent libtool to add system path (i.e. /usr/lib) to RUNPATH (rpath)?

Question

During testing (checking) MPFR libtool adds system path to rpath before testing path, i.e.:

0x000000000000001d (RUNPATH) Library runpath: [/usr/lib:/LFSC/native/src/bmpfr/src/.libs]

As a result, tests can run installed libs (in the first path (system)) instead of testing ones. This happens usually when reinstalling software. Maybe this affects installing of upgrades.

This is because of existing dependency’s .la file, e.g. libquadmath.la

Removing .la files resolves this problem.

But there is no reason at all to add system path into hardcoded RUNPATH.

Is there any way to resolve this problem without deleting .la files? Of course I know that I can change generated libtool script.

This is about hardcoded runpath in ELF file that has high priority against system path and LD_LIBRARY_PATH. You can ease understand this by compiling MPFR from source without installing. After make check run this in the source folder root: readelf -a tests/tversion | grep PATH You will see RPATH without system path. Then add libquadmath.la into gcc lib home e.g. /usr/lib/gcc/x86_64-linux-gnu/6/ remove tests and make check again, then check PATH in tversion again

# 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'

John Bollinger John Bollinger · Accepted Answer · 2020-02-01T15:40:02

But there is no reason at all to add system path into hardcoded RUNPATH.

Not so. Most systems have multiple directories in the default library search path, and in fact the search path sometimes changes when software is installed or removed. Putting the directory(-ies) where a given system library was actually located at link time into the RUNPATH for a given binary makes that binary more resistant to dynamically linking some other library of the same name at run time. It may also slightly accelerate dynamic linking.

Moreover, a binary's RUNPATH has lower precedence during dynamic linking than the LD_LIBRARY_PATH environment variable, so you can override RUNPATH at runtime in situtations such as the one you describe. That is the whole point of having RUNPATH in addition to RPATH, which has higher precedence than LD_LIBRARY_PATH.

During testing (checking) MPFR libtool adds system path to rpath before testing path, i.e.:

0x000000000000001d (RUNPATH) Library runpath: [/usr/lib:/LFSC/native/src/bmpfr/src/.libs]

I guess you mean that the build system is putting such entries into programs and libraries as built in the build tree. Libtool typically modifies runpath entries when it runs in (re-)install mode (which relies in part on the .la files). One would not expect to see build-tree directories in the runpath of a program or library once it has been properly installed on the system.

Note also that that's RUNPATH, not RPATH. As mentioned above, these are not the same thing.

As a result, tests can run installed libs (in the first path (system)) instead of testing ones. This happens usually when reinstalling software. Maybe this affects installing of upgrades.

If that happens when you run make check or when you run the programs via libtool operating in "execute" mode then you should raise an issue against MPFR about it. It is not an issue if that happens only when you run uninstalled test programs directly (but see also below).

Is there any way to resolve this problem without deleting .la files?

Generally speaking, one should expect to set LD_LIBRARY_PATH appropriately to run uninstalled programs or dynamically link against uninstalled libraries. make check should take appropriate measures automatically, and in a build system that uses libtool, that would probably take the form of running the binaries via libtool. Typically, an Autotools-based build system in fact creates wrapper scripts for built binaries to make that as transparent as possible.

With that said, removing the .la files is not necessarily unreasonable. Libtool has good reasons for creating them, but the residual benefit from installing them to the system along with the libraries themselves may not balance the drawbacks. RedHat, for one, has long held the view that it does not, so it in fact does not include the .la files in its RPM packages, and its packaging guidelines specify that third-party packagers should not do so either.

Ultimately, if you want to keep external .la files, unmodified, but avoid libtool drawing RUNPATH entries from them when it links, then your main alternative is to modify the project's libtool script. Details depend significantly on which version of libtool the project uses.

How to prevent libtool to add system path (i.e. /usr/lib) to RUNPATH (rpath)?

1 Answers