Re: Core updates status

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> Am Mon, May 06, 2024 at 10:47:13AM +0200 schrieb Josselin Poiret:
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>> > I don't mind too much; when we re-enable the change we should add a
>> > phase to the gnu-build-system automatically deleting/moving the libtool
>> > archives. so that we're covered.
>> 
>> I agree, although we'll have to be careful since some packages might
>> need them if they don't use pkg-config!
>
> I am a little bit confused by the suggestion; you mean removing all .la
> files from all packages?

Yes!

> I thought they were there for a reason, and usually recorded the
> dependencies. For instance, doing a "guix build mpc" and looking at
> libmpc.la, my impression is that I see correct information.

libtool records the *transitive* dependencies, as would be useful when
doing static builds but not shared builds, as the dependencies are
already recorded in the RUNPATH of the built ELF binaries.  For our
overwhelming common case (shared libraries) on GNU+Linux, these files
are thus unnecessary and when used they lead to over-linking (due to
listing the whole *transitive* dependencies) for shared library.  That
in turn muddles the dependency graph (as more references get retain in
the RUNPATH) and forces us to propagate more stuff.

> Why would
> one want to force upstream to add a pkgconfig dependency additionally
> to libtool? Or do I misunderstand the suggestion?

I hope my explanation above make it clear why libtool for our common
case of building shared libraries is not useful.

It could be useful when building shared libraries or targeting some
systems such as Android, which linker is very dumb or so I've heard. My
suggestion is to delete them by default, or move them to a 'libtool'
output when one is available (similarly to how we handle debug symbol
files).

-- 
Thanks,
Maxim