Re: Libtool Roadmap

[Sam James]

> On 10 Apr 2022, at 20:46, Alex Ameen <alex.ameen.tx@gmail.com> 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
Description: Message signed with OpenPGP