I think that we could add -lrt in configure script.
Solaris also has a problem for lock object.

Its pthread_mutex_t seems have alignment of 8-byte.
In posix-lock-obj.h, we will have a padding after vers and the union u.
So, it fails at assert (!"sizeof lock obj");

Reference:
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/types.h

due to pth-2.0.7/bin not being added to PATH

Maybe add configure parameter to ignore subarch for 99% of cases in which it
does not matter? This will avoid patching in most of the cases.

Yes.
I doubt that the subarch always uses the same ABI.

Thanks, but I do not understand the comment, do you suggest to patch this file
with every subarch out there? I still trying to understand why subarch is
important for the processing, it is a generic string.

FWIW, meanwhile there is a mapping table in src/mkheader.c:canon_host_triplet.

Did you had a chance to test the patch or 1.19?

The main page at bugs.gnupg.org explains that you should ask for updating your
role. I have done that now.

Duplicate of T1931

This has already been fixed in the repo:
commit c01c8f0c4f55d76b037c7f6aa44ad25ede18d38a
1.19 will soon be released.

D293: 592_0001-Use-assert-to-print-diagnosicts-before-calling-abort.patch

Can you please apply the attached patch which should help to get a more precise
error message. It might also be useful to show the file
src/lock-obj-pub.native.h
which is created int the build directory.

Please build libgcrypt directly and read README(cross-compiling).
I assume you are using libgpg-error 1.18, right?

So what? This is a wrapper for malloc thus it calles malloc with the args given
by the user.

No c+p of warnings please! Use gnupg-devel for such things.

No c+p of warnings please! Use gnupg-devel for such things.

No c+p of warnings please! Use gnupg-devel for such things.

Please STOP posting all warnings you see to the bugtracker. Use gnupg-devel is
you have questions. Thanks.

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