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.

Applied.

News for 1.34:

Topic branch of libgpg-error is not good to show changes (for other libraries).
So, I made D473: Introducing LDADD_FOR_TESTS_KLUDGE to enable 'make check' with LD_LIBRARY_PATH.
Appliying to libgpg-error.

For other distros, it seems it's quite old issue: https://sourceware.org/ml/binutils/2012-05/msg00037.html

My patches on the topic branch: https://dev.gnupg.org/source/libgpg-error/history/gniibe%252Fdisable-new-dtags/

My tentative conclusion: When (GNU) ld supports --disable-new-dtags, add it to LDADD in tests/Makefile.am.

Reading this discussion: http://lists.gnu.org/archive/html/bug-libtool/2018-01/msg00014.html
It seems that it could be fixed if we care about the order of libraries.
And it's not the issue for libgpg-error, which doesn't require external libraries.

For binutils, in Stretch, Debian specific patch was introduced.
Then, upstream introduced --enable-new-dtags option for configure to build binutils.
Now, Debian uses --enable-new-dtags option (at build time).