Here is the list:

• libgcrypt
• libassuan
• ntbtls
• gpgme : autogen.sh is ready
• npth

Please try: rA87c2bb5708ff: We can't support fd passing, if the system doesn't support it.
It disables the particular test.

I think that file descriptor passing is not supported on Cygwin.
We should disable the feature of libassuan.

It will be in the next release (2.4.4).
Thanks for reporting.

The description of this bug report is not correct.
_POSIX_C_SOURCE should *not* be defined to use INADDR_LOOPBACK for the system.

We don't support pkg-config, because it is not POSIX. See https://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028474.html for discussion.

Thanks for testing.

Confirmed that it now compiles ok on Fedora, thanks.

Thanks for the reminder. Fixed.
Note that LIBASSUAN_LIBS is not needed because it is already part of t_common_ldadd.

I'm still hitting this on Fedora. The patch is simple and was posted on the mailing list but apparently not incorporated into git:

This happens on at least PPC Mac OS X 10.4.11, Tiger. Compiler is by default Apple's
version of GCC 4.2. The error is reported as this:

libtool: compile: /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I..
-I.. -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -Wall
-Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith -MT
libassuan_la-assuan-socket.lo -MD -MP -MF .deps/libassuan_la-assuan-
socket.Tpo -c assuan-socket.c -fno-common -DPIC -o .libs/libassuan_la-
assuan-socket.o
assuan-socket.c: In function 'socks5_connect':
assuan-socket.c:732: error: 'INADDR_LOOPBACK' undeclared (first use in
this function)
assuan-socket.c:732: error: (Each undeclared identifier is reported only
once
assuan-socket.c:732: error: for each function it appears in.)
make[3]: * [libassuan_la-assuan-socket.lo] Error 1
make[3]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3/src'
make[2]: * [all] Error 2
make[2]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3/src'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3'
make: * [all] Error 2
make: Leaving directory
`/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3'
Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.or
g_release_tarballs_ports_devel_libassuan/libassuan/work/libassuan-2.4.3"
&& /usr/bin/make -w all

Cause is that the declaration of 'INADDR_LOOPBACK' is hidden behind some guards. The
two external links document the situation, they also offer patches, either the attached
one or this addition for src/assuan-socket.c:

//fix missing define in MacOSX 10.4 Tiger
#ifndef INADDR_LOOPBACK

#define INADDR_LOOPBACK (u_int32_t)0x7f000001

#endif

In ten days I'll be at home again with my Apple PowerBook G4 and might have time to
check the situation in Mac OS X 10.5, Leopard.

D380: 963_src_assuan-socket_INADDR_LOOPBACK.patch

See T2910.

I'm closing this bug due to inactivity. Feel free to reopen it with more
information.

I have seen that but pretty pelase describe it here so that we can also work
with email.

Detail info in https://trac.macports.org/ticket/51708
OS: PPC Tiger, Mac OS X 10.4.11
The build process is automated by macport.

Please describe exactly how you build Libassuan. Compiler, OS etc, error message.

2.4.3 has been released and I assume that this works now. Feel free to re-open
if it is not the case.

Patch applied with commit c52829e for 2.4.3.
Thanks.

Had you a chance to run the suggested test?

Thanks. Changed with commit 678f606 for 2.4.3

Thanks for the output. That indeed confirms my suspicion. Let's read it together:

[...]
libassuan.so.0 =>
/home/ann/gnupg-2.1.11/libassuan-2.4.2/src/.libs/libassuan.so.0 (0x002e4000)
libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0x0066d000)

ldd says which library is used to satisfy a dependency at load time. You see
here that for libassuan.so.0 your newly built library is used. That is good.
However, for libgpg-error.so.0 the library from your system is used which does
not have gpgrt_asprintf, hence the error message in your first log.

What you need to do is to make sure the runtime linker finds your gpg-error
library. Since this kind of problem will occur for each library, it is best to
install all the libraries you built to a common prefix, say /home/ann/local or
/usr/local by specifying --prefix=/my/prefix at configure time, and then to set
LD_LIBRARY_PATH to /my/prefix/lib and include /my/prefix/bin in PATH, so that
gpg-error-config and libassuan-config and co are found at compile time. Feel
free to ask questions if you get stuck.

(If you don't want to do all this by hand, and merely want a working modern
GnuPG, you can also use the 'speedo' framework. See the README in the GnuPG
repository for some hints.)

Thank you. I've attached the output from 'ldd tests/fdpassing'. Not sure how to
read it.

I don't think the bugs are necessarily related. Your issue looks like you build
your own libgpg-error and linked fdpassing against that, but your runtime linker
uses your system-supplied libgpg-error. Try running 'ldd tests/fdpassing' to
see which libgpg-error is used at run-time. Feel free to ask if you need more
assistance.

Hello,

please run:

  strace -f -E srcdir=tests -o fdpassing.strace tests/fdpassing

and attach fdpassing.strace to this bug report.

Duplicate of T2318

What distribution are you using? You are probably better off using their
supplied binaries, which are hopefully tested.

Version 2.4.0 has been released which replaces the used vasprintf code.

FWIW: The not too long term plan is to replace the use of vasprintf.c by
functions from libgpg-error which is used anyway.

Re-assigning to gnupg. libassuan works correctly, afaics.
When trying to send back Zack's key I had the same problem last week and
increased the limit in dirmngr (84f4c8811fc5bdd78693c4dc289389a8337cc257).
I also mentioned that in a comment to another Debian bug report.

However, their should not be a hang but a proper error diagnostic; it is on my list.

with 2.1.7, i see no hang, but i do see failure with certain large certificates,
like 0xB27B944E34884E85:

0 dkg@alice:~$ gpg2 --send 0xB27B944E34884E85
gpg: sending key 0xB27B944E34884E85 to hkps server hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Too much data for IPC layer
gpg: keyserver send failed: Too much data for IPC layer
2 dkg@alice:~$

maybe the boundary is 500KiB? I don't have this problem with my own OpenPGP cert:

0 dkg@alice:~$ gpg2 --export 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 | wc

3126   11384  481051

0 dkg@alice:~$ gpg2 --export 0xB27B944E34884E85 | wc

4310   13779  541937

0 dkg@alice:~$

Can you please downgrade to libgpg-error version 1.12 and try again?
I assume that there is a conflict between Pth and the Pthread mutexes from
libgpg-error > 1.12.

You may also consider to update to GnuPG 2.1.3 which does not use Pth anymore.

Please show us the version of your gpg-agent and its configuration
(~/.gnupg/gpg-agent.conf).
The version of gpg-agent is usually expected to be same one of gnupg, and the
invocation is:

/opt/freeware/bin/gpg-agent --daemon /bin/<SOMESHELL> # to invoke subshell
or
/opt/freeware/bin/gpg-agent --daemon # to be background

GnuPG invokes gpg-agent with --use-standard-socket-p to check if gpg-agent exists,
but it seems your GnuPG failed here waiting finish of gpg-agent.

Plerase write proper bug reports or discuss at gnupg-devel. Thanks.

Updated status to 'unread'. I'm not chatting.