Related to the (not supported) Cygwin platform ( Unix emulation on Windows)
Feb 6 2020
Thanks. Fix goes into 1.37.
May 21 2019
In master, I pushed a change, closing.
For future, it would make sense applying your patch, but I wonder if it works on macOS.
Let me check.
Apr 30 2019
Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.
Please explain in more detail what the problem with Cygwin is.
Apr 9 2019
We do not support 64 bit Windows thus this problem on Cygwin is obvious. Funny that Cygwin falls back to native Windows object in this case.
Apr 8 2019
Jul 8 2018
Some times I a curious and it seems that GnuPG can be used on 32 bit Cygwin. Thus I wonder what is going on on 64 bit Cygwin (which I don't know). It might be a HANDLE/socket issue where Windows is still using values which fit into a 32 bit integer but Cygwin might have changed that. Eventually we need to remove that assumption in GnuPG's code and this is why I won't have a problem to keep this bug open.
Given that Cygwin is not supported I would understand if the bug is
closed or should I open a feature request to have Cygwin officialy
I would never the less appriciate any help/hint on how to be successfull
installing "gnupg" on Cygwin.
Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant.