Re: MSW DLLs support in libtool

[Vadim Zeitlin]

Peter Rosin <peda <at> lysator.liu.se> writes:

> On 2016-02-11 00:38, Bob Friesenhahn wrote:
> > 
> > Also, "-no-undefined" does not indicate if the library has undefined
> > symbols (many DLLs have undefined symbols).

 Sorry but this is just completely incorrect as written. It's very probable
that you meant something else from what you wrote, but just to avoid
creating even more confusion in this discussion I'd like to ensure that we
all agree and understand that DLLs (as in "Windows dynamically loaded
libraries") never have any undefined symbols, this is the whole point.

> > It indicates that the build configuration has agreed to supply any
> > additional dependency libraries if there otherwise would be undefined
> > symbols.
> 
> Well said, I would also like to add that libtool -no-undefined *does* *not*
> imply ld --no-undefined.

 This is, of course, a bug. I don't even know if it's worth continuing to
argue because I don't have anything new to add to what I had already
written and it is IMO quite obvious to any user of libtool that it should
imply it, yet most people here seem to consider it as a feature.

 Really, how exactly can the fact that the libtool option with the same
name as a linker option doesn't work in the same way be rationalized?
Especially when libtool is known to reuse the linker options in other cases
(e.g. -shared, -static, ...)? What possible advantage can there be in
allowing to create shared libraries with undefined symbols even if the
libtool library uses -no-undefined?

> I.e. If you add libtool -no-undefined, then the *only* thing that changes
> is that libtool actually attempts the shared build.

 This behaviour is completely nonsensical as well. There is already
--enable-shared for this! Libtool should attempt the shared build if it's
enabled.

> How the shared build is performed is not changed in any way, so
> if there actually are undefined symbols (not supplied by the build etc etc)
> and the platform can handle that, then that will continue to work.

 Or it won't work, but you'll learn about it when the library can't be
loaded on the user's system. Which is, of course, vastly preferable to
getting a link error if libtool passed --no-undefined to linker as every
sane person would expect it to do.

> Conditionally adding -no-undefined for systems where it matters is overly
> defensive.

 Sorry, what does this mean exactly? It's being said that libtool should
leave the control to the application developer. If the application
developer decided to use -no-undefined, why doesn't libtool pass it on to
the linker? Could the application developer intention really be anything
other than this?

 And, conversely, if you insist that libtool -no-undefined should not imply
--no-undefined for ld and should just enable the shared library build, why
is this option used instead of --enable-shared which would seem to be much
better suited to be the option which, well, enables shared libraries?

 I really don't know how to argue against this because whichever way I try
to understand the current libtool behaviour it just doesn't make any sense...

> Repeat after me:
> 
>     libtool -no-undefined is not at all the same thing as ld --no-undefined.

 I don't want to repeat it, I want to change this and make -no-undefined
option in a way a reasonable person might expect it to.

 Regards,
VZ