Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

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 `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 
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.

-Alex


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.
>
> Bob