RE: Libtool Roadmap
<mailto:aixto...@felt.demon.nl>
Michael Felt
Mobile +31 (0)6 5184 4181
Email aixto...@felt.demon.nl
From: Libtool On Behalf Of
Alex Ameen
Sent: Sunday, 10 April 2022 21:47
To: libtool@gnu.org
Subject: Libtool Roadmap
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.
[] …
I have used libtool on AIX with xlc/xlC and generally speaking don’t have any
major issues.
Feedback: based on `roadmap` text:
AFAIK – AIX loader does not understand .la or .lt – and, as the comment
mentions about packagers – I delete both .la and .lt before packaging. I prefer
my shared libraries in AIX archives (macOS terms – fat library), but AIX loader
also accepts (default search) `libfoo.SO` as long as it is the correct ABI
(32,64-bit).
As to personal preferences – because AIX supports libfoo.a with mixed ABI
members I do not like lib64/libfoo.so and lib/libfoo.so solutions.
FYI: I use DESTDIR with `make install` and then package the DESTDIR.
FYI: AIX does not fall over -R, but can influence the libfoo.a(libfoo.EXT)
default search path for dependent libraries. Been a while since I have had to
look at that. Note: just checked. According to man page -R is only valid when
-bsrv4 is also specified. I prefer not to see -bsrv4 on AIX.
For the rest – I guess I am a simple user – as I have never encounter issues
with any of them (and wonder if they even have relevance on AIX).
Also, cannot say what the impact is of using the GNU ld program, rather than
the (default) AIX ld program.
_
━
LIBTOOL-ROADMAP
Alex Ameen
━
Table of Contents
─
1. Roadmap
.. 1. Improve `.la' libraries, or phase them out on certain platforms.
. 1. Libtool should not use `libfoo.la' when `libfoo.EXT' are requested.
. 2. Make installation of `.lt' libraries optional.
. 3. Prevent over-linking of ELF binaries.
. 4. Security
.. 2. Support `$ORIGIN' in ELF binaries’ `RPATH' and `RUNPATH' entries.
.. 3. Avoid use of wrapper scripts for `noinst_' and `nodist_' binaries.
.. 4. Refactor argument parsing, particularly parsing linker flags.
.. 5. Migrate platform, arch, and tool specific conditionals to `autoconf'.
.. 6. Expand usage of `M4SH' for creating `ltmain.sh' and `libtoolize.in'.
.. 7. Simplify `bootstrap' process.
.. 8. Make the creation of test cases more user friendly
.. 9. Create CI pipeline resources for distribution and tool maintainers
.. 10. Permit installable LTLIBRARIES to conditionally be “convenience
libraries”
Re: Libtool Roadmap
> On 10 Apr 2022, at 20:46, Alex Ameen 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
Libtool Roadmap
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. The only notable item I have not included here is some organizational changes concerning how bugs/patches are submitted ( currently there's 3 ways to submit bug reports and 2 of them are miserable to process ); but I'll address that in another thread. Also note that in my discussion of "CI" ( Continuous Integration ) setup, I intend to provide sufficient abstraction that with some tailoring automated `libtool' testing can be accessible to other developers. This will not be a "core" feature of `libtool', it is rather a practical necessity for maintenance. I am not and will not be making commitments on behalf of the `libtool' team to gate releases based on regression for any particular combination of platforms or tools. Rather you can look at this as "I want to improve the existing Hydra infrastructure, make it more accessible, and find ways to support platforms which cannot natively run Nix or Hydra", this may mean creating more abstract job declarations in a format with can be processed by a wider range of CI tools, it may mean VMs will be used for some testing, it may mean that Hydra is dropped altogether ( unlikely ). Time will tell. 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. ━━━━━━━━━ LIBTOOL-ROADMAP Alex Ameen ━ Table of Contents ─ 1. Roadmap .. 1. Improve `.la' libraries, or phase them out on certain platforms. . 1. Libtool should not use `libfoo.la' when `libfoo.EXT' are requested. . 2. Make installation of `.lt' libraries optional. . 3. Prevent over-linking of ELF binaries. . 4. Security .. 2. Support `$ORIGIN' in ELF binaries’ `RPATH' and `RUNPATH' entries. .. 3. Avoid use of wrapper scripts for `noinst_' and `nodist_' binaries. .. 4. Refactor argument parsing, particularly parsing linker flags. .. 5. Migrate platform, arch, and tool specific conditionals to `autoconf'. .. 6. Expand usage of `M4SH' for creating `ltmain.sh' and `libtoolize.in'. .. 7. Simplify `bootstrap' process. .. 8. Make the creation of test cases more user friendly .. 9. Create CI pipeline resources for distribution and tool maintainers .. 10. Permit installable LTLIBRARIES to conditionally be “convenience libraries” 1 Roadmap ═ 1.1 Improve `.la' libraries, or phase them out on certain platforms. 1.1.1 Libtool should not use `libfoo.la' when `libfoo.EXT' are requested. ╌ What I mean is, if I say `-lfoo', of `-l:libfoo.la', then go right ahead, do your thing `libtool'. However, when I went out of my way to say `-l:libfoo.so' or `/trust/the/user/libfoo.a', it is evil for `libtool' to silently decide that it knows best and decide to use `libfoo.la' regardless. • This behavior leads a large number of package managers and distributions to delete `.la' files before distributing binary tarballs. • This frequently leads to incorrect/unexpected libraries and flags being used because they were written as dependencies or inherited flags in a `.la' file. 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+
Re: Libtool roadmap
On 3/31/22 11:02, Jeff Squyres (jsquyres) wrote: > Other than Bob's humorous reply, any comment from the Libtool team? I'm also interested in any thoughts about the long term roadmap for libtool. Like you, I think users can ask these questions out of a genuine interest to align downstream development where possible. Thanks for asking the question Jeff. -- Cheers, Carlos.
Re: Libtool roadmap
Other than Bob's humorous reply, any comment from the Libtool team? Thanks! -- Jeff Squyres jsquy...@cisco.com From: Bob Friesenhahn Sent: Friday, March 25, 2022 4:01 PM To: Jeff Squyres (jsquyres) Cc: libtool@gnu.org Subject: Re: Libtool roadmap On Fri, 25 Mar 2022, Jeff Squyres (jsquyres) wrote: > Congratulations on the Libtool 2.4.7 release! > (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) > > Given that this is the first Libtool release in ~7 years, should we -- the > general developer community -- take this as an indication that the GNU > Libtool is back under active development? If so, is there a roadmap and/or > set of timeframes for future GNU Libtool work? >From the above, it sounds like you are interested in being a libtool developer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Libtool roadmap
On Fri, 25 Mar 2022, Jeff Squyres (jsquyres) wrote: Congratulations on the Libtool 2.4.7 release! (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) Given that this is the first Libtool release in ~7 years, should we -- the general developer community -- take this as an indication that the GNU Libtool is back under active development? If so, is there a roadmap and/or set of timeframes for future GNU Libtool work? From the above, it sounds like you are interested in being a libtool developer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Libtool roadmap
Congratulations on the Libtool 2.4.7 release! (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) Given that this is the first Libtool release in ~7 years, should we -- the general developer community -- take this as an indication that the GNU Libtool is back under active development? If so, is there a roadmap and/or set of timeframes for future GNU Libtool work? Thanks for any information that you can provide. -- Jeff Squyres jsquy...@cisco.com
