Howdy Bob,

I totally agree with you. `libtool' definitely should not be creating solutions that only work with a particular linker in mind, and at a high level I think it should ultimately work to provide a sense of consistency across a variety of linkers.

In this case my concern is about ease of use for developers who might be confused about `libtool', `ld', and other link-editors having options with identical names which behave in very different ways. Here we have the flags `--whole-archive', `--no-whole-archive', and `--export-dynamic' which exist across almost all popular link-editors, GNU `ld' ( `ld.bfd' and `' ), LLVM's `lld', Solaris' `ld', etc which have a consistent behavior. With that in mind I think having the flag `-export-dynamic' in `libtool' behave differently from "the norm" in discreet ways would likely cause confusion. To my knowledge HP UX and AIX are the only two systems which lack these flags ( I believe this is actually the type of thing that `libtool' should aim to port to those platforms ).

And yeah I agree that convenience libraries are wonky, and that linking static archives into dynamic libraries and executables is a tricky task. The good news on this front is that this is actually the area of linking and loading that I have the most experience in, and I'm familiar with many ( but not all ) of the pitfalls that pop up on Linux especially, but also with AIX and Windows. The reason I recommended the use of a convenience library in this case is because `libtool' already knows to use `--whole-archive' and `--no-whole-archive' for these libraries, so it is a convenient way to accomplish those goals in existing releases.

I took a look at the option parsing for `libtool --mode=link' in depth yesterday and I know why it has trouble handling `--whole-archive' and `--no-whole-archive' flags, fixing the issue isn't trivial just because of how the parser is written but I plan to get these flags to behave "as expected" for folks who are used to this feature in common link-editors.

Overall I think we're on the same page. I understand that `libtool' is ultimately intended to provide cross-platform consistency as a portability wrapper around each platform's various compilers, linkers, and loaders. It is certainly not my intention to promote a specific tool or platform over another.


On 11/21/21 8:32 AM, Bob Friesenhahn wrote:
On Sat, 20 Nov 2021, Alex Ameen wrote:

Thanks for the follow up, this gave me a much clearer idea of the underlying issue that you're trying to solve. I really do appreciate you taking the time to help improve `libtool'.

You're absolutely right that `libtool' completely bungles the use of `--whole-archive' and `--no-whole-archive' which I see as a high priority issue. In several build systems I've built in the past I have needed to apply manual patches to `libtool' to work around this, and I plan on merging changes to fix this soon ( I'm taking my time to create test cases ).

I don't pretend to understand the associated issues, but please take care that libtool does not promote solutions which only work with GNU ld (or linkers designed to perfectly emulate GNU ld) on a limited set of targets.

Libtool is a portability solution to encourage development of software which is able to compile and run on many targets, even if the authors of the software have never experienced those targets.

Linking static libraries into shared libraries is a complex topic and is a reason why libtool offers the clumsy/inefficient "convenience library" mechanism since it assures that the objects were compiled properly to be used in the library they are linked into.


Reply via email to