Re: Libtool Roadmap

Sam James <[email protected]> Wed, 13 Apr 2022 02:28:42 +0100
Newsgroups	gmane.comp.gnu.libtool.general
Message-ID	<[email protected]>

> On 10 Apr 2022, at 20:46, Alex Ameen <[email protected]> wrote:
> 
> Howdy, a few weeks ago I talked about sending out a road-map.
> I've gotten that prepared today. This roadmap is informal, opinionated, and I encourage feedback and discussion on it. I have my own biases and opinions about things I like/dislike and want added based on my `libtool' usage over the years. However, I would be doing a disservice to users if I forced them to adopt "my way of using `libtool'" over their own. With that in mind it's important for y'all to share your own use cases and pain points so that I can address them. This might be more accurately called a "giant RFC dump" than a roadmap, because it's hard for me to imagine that this remains unchanged.
> 

Thanks for sharing your vision and it sounds pretty spot on with what I've been hoping for!

> 
> 
> These tasks are what I have in mind for the immediate future. Long term I'd like to work more closely with the other Autotools teams to improve integration with the rest of the family, and make `libtool' more extensible, but those are conversations for another day.
> 
> [snip]

> 1.1.2 Make installation of `.lt' libraries optional.
> ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
> 
>   • Closing Argument:
>     ┌────
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     │     libtool: link: warning: library `/tmp/usr/lib/libstdc++.la' was moved.
>     └────
>     Should people learn to use `DESTDIR'? Sure, but it’s hard enough to
>     defend the usefulness of `.la' when it has a meltdown like this over
>     binaries which were safely moved.


This would be a nice win for downstreams.

> 
> 
> 1.1.3 Prevent over-linking of ELF binaries.
> ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
> 
>   Unless a popular patch for `ltmain.sh' was applied to a project,
>   `libtool' will over-link unneeded dependencies in ELF binaries. This
>   often leads to unexpected/incorrect library load/initialization
>   ordering, particularly in cases where libraries have circular
>   dependencies.
>   • “Libraries shouldn’t have circular dependencies” is not a valid
>     excuse.
>   • This has a measurable impact on performance in large applications,
>     and makes interposing symbols nearly impossible.
>   • This behavior severely aggravates C++ initialization ordering
>     issues.
>   • Makes the use of ELF filtering extensions impractical.
> 
> 

Really chuffed to see this here!

> [snip]
> 1.3 Avoid use of wrapper scripts for `noinst_' and `nodist_' binaries.
> ──────────────────────────────────────────────────────────────────────
> 
>   “When possible” of course. While these scripts mean well, they are
>   difficult to circumvent when a use case requires direct execution of a
>   binary. Further, the availability of `$ORIGIN' on ELF platforms makes
>   these wrappers unnecessary or counter-intuitive.
> 

And this.
signature.asc (application/pgp-signature, 618 B)