I have only been pulling from .tar.gz files.

I think that I fixed this issue in master. If you have time, please test, from
git repo.

awk --version
GNU Awk 4.1.1, API: 1.1 (GNU MPFR 3.1.3, GNU MP 6.0.0)
Copyright (C) 1989, 1991-2014 Free Software Foundation.

Running the filter from the CLI: nothing happens.
root@/home/actionmystique/Program-Files/Ubuntu/GnuPG/git-libgpg-error# awk
'/^\"POT-Creation-Date:/&&!s{s=1;next};!/^#: /{print}'

^C

Ibraheem very kindly tested again. However, it is still not working completely.
He writes:

It's still core dumping... Out of curiosity, I explicitly defined

'USE_DOUBLE_FOR_ALIGNMENT 1' and the checks were passing on Solaris with no more
core dumps. I guess that means they're on the right track, just have to get the
preprocessor directives right for gcc and Solaris.

Full details are in
https://mail-index.netbsd.org/pkgsrc-users/2016/03/01/msg023078.html

Running from the command line with gawk and mawk, I don't get an error message.
What version of awk are you using? Does this occur when triggering this from
the command line or only when running it from smartgit?

Thank you for clarification. I didn't know that pkgsrc supports other
platforms. Now, I understand.

I changed more:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=34b07146bbb0863436fc9381a84314b18bdfb807;hp=49655fb6ef39b307787e1b6e00c996f9c7db64f7

The intention is that USE_DOUBLE_FOR_ALIGNMENT for Solaris 32-bit version.
I thought that checking ILP32 worked (but not, in fact). I believe that LP64
checking works (at least with GCC).

I'm working on pkgsrc, which is a portable packaging system origination on
NetBSD. I myself work mostly on NetBSD.

However, we have patches for non-NetBSD platforms in pkgsrc, and this patch was
worked on by the two people mentioned earlier. Since I can not test on Solaris,
I asked them to test on Solaris, and Ibraheem did that.

I hope that clears it up.

Let me clarify/confirm. Does it work on Solaris? And now do you speak for NetBSD?
My fix is specific to Solaris (no matter if it's Sparc or not). It doesn't
handle any issues for NetBSD.

I seems that Sparc GNU/Linux doesn't have this alignment issue, but (for me) it
is highly likely that sparc architecutre requires the alignment of 8-byte.

Thank you for the patch.
I don't have the environment, but I asked the original reporter to test.
Sadly, his reply is negative, see:

https://mail-index.netbsd.org/pkgsrc-users/2016/02/27/msg023071.html

Thank you for your report. Yes, it is the alignment issue.

Please try:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=5168b97fb5e2eebdc99b40f96f9b6289647e87d2

Fixed in
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=5168b97fb5e2eebdc99b40f96f9b6289647e87d2

Please test.

Thanks for debugging this. An alternative for your patch would be to use
es_fileno_unlocked but your idea is also fine.

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!