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 `ld.gold' ), 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
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
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.