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

Ileana Dumitrescu <[email protected]> Thu, 15 Aug 2024 18:51:53 +0300
Newsgroups	gmane.comp.gnu.libtool.bugs
Message-ID	<[email protected]>
Severity: wishlist

On 14/08/2024 06:18, Sam James wrote:
> Hi!
> 
> At the moment, it looks like fast-install is disabled on Linux:
> 
> # 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.
> 
> (I've tried to follow the logic through but failed. It's not clear to me
> why Linux needs this opt-out. I'm sure there *is* a reason, I just can't
> spot it yet.)

Looking through the documentation:

"""
@defvar fast_install
Determines whether libtool will privilege the installer or the
developer.  The assumption is that installers will seldom run programs
in the build tree, and the developer will seldom install.  This is only
meaningful on platforms where @code{shlibpath_overrides_runpath} is
not @samp{yes}, so @code{fast_install} will be set to @samp{needless} in
this case.  If @code{fast_install} set to @samp{yes}, libtool will create
programs that search for installed libraries, and, if a program is run
in the build tree, a new copy will be linked on-demand to use the
yet-to-be-installed libraries.  If set to @samp{no}, libtool will create
programs that use the yet-to-be-installed libraries, and will link
a new copy of the program at install time.  The default value is
@samp{yes} or @samp{needless}, depending on platform and configuration
flags, and it can be turned from @samp{yes} to @samp{no} with the
configure flag @option{--disable-fast-install}.

On some systems, the linker always hardcodes paths to dependent libraries
into the output.  In this case, @code{fast_install} is never set to 
@samp{yes},
and relinking at install time is triggered.  This also means that 
@env{DESTDIR}
installation does not work as expected.
@end defvar
[...]
@defvar hardcode_into_libs
Whether the platform supports hardcoding of run-paths into libraries.
If enabled, linking of programs will be much simpler but libraries will
need to be relinked during installation.  Set to @samp{yes} or @samp{no}.
@end defvar
"""

If I understand, hardcoding run-paths into libraries causes the
relinking during installation, which makes fast_install not possible.

I am not sure of all the implications of removing the hardcoding of
run-paths in libraries, except that linking of programs will be more
complex. For now, I think it would be best to look more into this
after the stable release, but if anyone has any ideas or corrections,
please add them here.

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, 6.3 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)