It is just warning which does not matter if you are using a released tarball.
The next release will support newer autotools and has updated helper files.

No we can't stop doing that. The cleanup function is required to flush the
internal buffers. atexit is a standard C function - dlopen is only a sometimes
useful kludge.

Hm, the suggestion of linking with libgpg-error doesn't really
scale -- think in terms of someone providing pre-built binaries
for e.g. apache and/or php. Where does it end? Should these
programs be linked with all potential otherwise loadable modules?
Why should libgpg-error be special in this regard?

Also, doesn't using atexit() make this problem far worse?
Perhaps libgpg-error can stop doing that, at least?

All kind of problems may appear if you dlopen libgpg-error. It is possible to
do this on Windows due to the very different architecture but Unix/ELF is too
limited to work correctly. The bug you see is just one on the surface - tehre
are lot of other problems below the surface.

In short: Do not dlopen libgpg-error.

You better link apache with libgpg-error so that other dlopen stuff may use the
already loaded code.

BTW, the segmentation faults have been observed
with apache and "stand-alone" php.

D269: 525_patch-src_estream.c

I try to imagine where the subarch can cause an issue, maybe a big fat warning
when mapping should be sufficient at this point?

For now I will add a note for everyone that opens a bug for this reason to
duplicate the unknown subarch into his own, package will not be compiled
automatically for these.

Thanks!

But that also introduces a new class of bugs. I think it is easier to simply
add a new file. If it eventually turns out that we have too many identical
files, we can change that by adding a mapping table to mkheader.

The generated header file is, as expected, identical to the one we use
when cross-compling (modulo that we put both versions into one file).
Thus I came up with a simpler solution (see below). I'll commit it soon and a
release will also follow today.

+force_use_syscfg=no
if test "$have_w32_system" = yes; then

AC_DEFINE(HAVE_W32_SYSTEM,1,[Defined if we run on a W32 API based system])
if test "$have_w64_system" = yes; then

@@ -461,11 +462,17 @@ if test "$have_w32_system" = yes; then

  AC_DEFINE(HAVE_W32CE_SYSTEM,1,[Defined if we run on WindowsCE])
  GPG_ERROR_CONFIG_ISUBDIRAFTER="gpg-extra"
fi

+ force_use_syscfg=yes
fi
+if test x$cross_compiling = xyes; then
+ force_use_syscfg=yes
+fi
+
AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes)
AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes)
AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes)
AM_CONDITIONAL(CROSS_COMPILING, test x$cross_compiling = xyes)
+AM_CONDITIONAL(FORCE_USE_SYSCFG, test x$force_use_syscfg = xyes)

AC_DEFINE_UNQUOTED(HOST_TRIPLET_STRING, "$host", [The host triplet])

Modified src/Makefile.am
diff --git a/src/Makefile.am b/src/Makefile.am
index 65f8513..efc5970 100644

• a/src/Makefile.am

+++ b/src/Makefile.am
@@ -262,9 +262,9 @@ parts_of_gpg_error_h = \

 	w32ce-add.h      	\
 	$(lock_obj_pub)

• If we are cross-compiling we better make sure that no stale native
• lock include file will be found by mkheader.

-if CROSS_COMPILING
+# If we are cross-compiling or building on Windows we better make sure
+# that no stale native lock include file will be found by mkheader.
+if FORCE_USE_SYSCFG
pre_mkheader_cmds = -rm lock-obj-pub.native.h 2>/dev/null

and this is for i686 build

yes, i can. this is a gpg-error.h for x86_64 build.

Can you please paste the generated file?

This is additional patch for previous message, you'r tracker not allow to
attach more than one file.

D248: 510_07-windows-build.patch

D249: 509_09-fix-generating-union.patch

Werner, we (I'm and Alexpux) was made fix for windows build (x86_64 and i686)
and seems like it works. Patches in attachment. If you want to look at msys2's
libgpg-error package you may use this link https://github.com/Alexpux/MINGW-
packages/tree/master/mingw-w64-libgpg-error