Thank you. Merged.

I've just pushed rE732855a483709345a5c0f49504f45cb8da3f883a to dkg-fix-T4643 in the gpg-error git repository. I don't know why it is not yet visible here.

Thanks for the feedback. I'll go ahead and close any tickets that come in via debian that expect to be able to cross compile without having at least once had a native compiler on the platform to generate the appropriate lock-obj-pub-*.h.

In fact this specific scheme of indirect access to pthread objects is there to minimize dependencies of libgpg-error. It makes cross-compiling a bit harder but that is anyway the case because you need to check a lot of things for a new platform.

It is on on my private todo list but thanks for opening a puplic issue for tracking.

Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.

Fix pushed.

I think that detecting strerror_s by configure is better, because it's a new feature on Windows.

I think that when using GNU autoconf's configure, you should have the ${prefix}/bin in your PATH.

I guess we can do that. Thanks for the hint.

Thanks for your report.
Let me handle issue by issue.

We update condig.{guess,sub} only when needed. In the past we had cases with regressions on some rare platforms.

It is because you don't have ${prefix}/bin in your PATH.
Please build having /var/tmp/bin in your PATH.

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.

For reference our downstream tracker of this is https://bugs.gentoo.org/683254 including patches

Added a fix to GnuPG, too (master and stable 2.2).

I keep this ticket open, since it is also problem for other packages.

Similar issue with ntbtls:

FWIW:
The first config.log is from a gnutls build.
The second for libassuan 2.5.3 and has been configured:

./configure --enable-shared --prefix=/var/tmp --libdir=/var/tmp/lib64

Okay, I see the problem. The microsoft toolchain is more picky about de-facto standard use patterns with common blocks and the author of that code was not ware of this. Thanks for reporting, will be fixed in the next release.

This is not about a function, but about the variable _gpgrt_functions_w32_pollable. And this is not about exporting the variable from the library, but about declaring it as extern in gpgrt-int.h, so that gpgrt-int.h can be included in multiple translation units without defining the variable in each.

This function is not exported on purposes. Even the name of the header file indicates that tis is internal. External, that is public functions of the API, are defined gpgrt.h and only made externally visible by including them in the .def file. This has not been done and so I don't understand your bug report.