> On 10 Apr 2022, at 20:46, Alex Ameen <alex.ameen...@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
