Subject: bug#72613: Lack of fast-install on Linux proves painful w/ LTO

From: Nick Bowler <[email-masked]>
Date: Thu, 15 Aug 2024 13:12:18 -0400

On 2024-08-13 23:18, Sam James wrote:
> At the moment, it looks like fast-install is disabled on Linux:

I think the comment is very out of date.

> # This must be glibc/ELF.
> linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*)
>   version_type=linux # correct to gnu/linux during the next big refactor
>   need_lib_prefix=no
>   need_version=no
>   ...
>   # This implies no fast_install, which is unacceptable.
>   # Some rework will be needed to allow for fast_install
>   # before this can be enabled.
>   hardcode_into_libs=yes
> 
> This is particularly painful when using LTO, as you end up with a pretty
> time-consuming relink for something which is in theory avoidable.

On GNU/Linux, I believe relink should only be performed for uninstalled
shared libraries that link against other uninstalled shared libraries.

This is needed because the necessary runpaths are, as suggested by the
name hardcode_into_libs, hardcoded into libraries.  You can see this by
running readelf on such libraries in the build tree.  This has to be
changed to remove the build location when the libraries are ultimately
installed, and the way libtool currently does that is by relinking.

For normal libraries which do not depend on uninstalled shared libraries,
and for programs, no relinking is expected on GNU/Linux, so you should be
able to avoid this if you can restructure your project to avoid such
transitive dependencies between uninstalled shared libraries.

For the special case where libraries are located in the same build
directory and also installed into the same directory, on some platforms
(at least Solaris and GNU/Linux) Libtool could perhaps be changed to
generate runpaths using ${ORIGIN} which would not need to be changed
on installation.  That might help avoid relinks in certain cases.

Cheers,
  Nick