[PATCH] Cygwin needs -no-undefined libtool flag.

[Michael Haubenwallner]

On 03/07/2017 08:27 PM, Werner Koch wrote:
> On Mon,  6 Mar 2017 18:04, michael.haubenwallner at ssi-schaefer.com said:
> 
>> Cygwin is not a "real" Win32 system, but uses the Win32 binary format,
>> so libtool needs the -no-undefined flag.
> 
> This needs to be patched in libtool and not in libgpg-error et al.  it
> might be that upstream libtool already has that.  However due to
> problems we had with the upstream version we keep our version which has
> a few patches we require.

Well, there's nothing libtool can do about here.  Instead, there's a
(widespread) misinterpretation about the -no-undefined libtool flag.

Agreed this might be easier to understand when it were not a "no-"flag,
but this is for historical reasons when there were static libraries only.


Please let me try to explain:

Creating a static library does not need to know which libraries to link
against, as no linking is done at all.  So libtool does not require
library maintainers to specify enough libraries to resolve all symbols.

But with the introduction of shared libraries this requirement changed:
While each operating system does "support" undefined symbols with static
libraries, some operating systems also do support undefined symbols with
shared libraries, but some don't.

On the other hand, each operating system supporting shared libraries
obviously does support shared libraries without undefined symbols.

Without the -no-undefined flag, libtool assumes the library does have
undefined symbols, and does not create the shared library when the
operating system is known to lack support for undefined symbols in
shared libraries.

With the -no-undefined flag, libtool knows that the library maintainer
does provide necessary libraries to resolve all symbols, so libtool can
create the shared library even on operating systems without support for
undefined symbols in shared libraries.


As far as I can see, libgpg-error does not rely on undefined symbols at all.

So -no-undefined really makes sense for any platform here, as proposed in
https://lists.gnupg.org/pipermail/gnupg-devel/2016-November/032186.html

Beyond that: With linkers that support yelling on undefined symbols (like
GNU ld with -zdefs flag), the -no-undefined flag allows to unhide obscure
bugs related to undefined symbols at library linking time already.

However, because of the -zdefs (or similar) linker flag (where supported),
I can understand not to add the -no-undefined flag in minor releases,
to not unhide bugs that do not (seem to) harm when left hidden.

Uhm, lots of inversive logic here...

Thanks!
/haubi/