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.

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

Here's the updated output with line numbers.

51121==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 12 byte(s) in 1 object(s) allocated from:

#0 0x49f22b in __interceptor_malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x4dc25a in socketpair_connect

/home/gpg-user/gcrypt-2.0-sanitize/libassuan-2.2.0/src/assuan-pipe-connect.c:317:15

#2 0x4bdec1 in main

/home/gpg-user/gcrypt-2.0-sanitize/libassuan-2.2.0/tests/fdpassing.c:291:13

#3 0x2afdc8bddec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

Direct leak of 7 byte(s) in 1 object(s) allocated from:

#0 0x49f22b in __interceptor_malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x4bc978 in xmalloc

/home/gpg-user/gcrypt-2.0-sanitize/libassuan-2.2.0/tests/./common.h:62:13

#2 0x2afdc8bddec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

SUMMARY: AddressSanitizer: 19 byte(s) leaked in 2 allocation(s).

51122==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3784 byte(s) in 1 object(s) allocated from:

#0 0x49f22b in __interceptor_malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x4bed76 in assuan_new_ext

/home/gpg-user/gcrypt-2.0-sanitize/libassuan-2.2.0/src/assuan.c:134:11

#2 0x4bde6f in main

/home/gpg-user/gcrypt-2.0-sanitize/libassuan-2.2.0/tests/fdpassing.c:287:13

#3 0x2afdc8bddec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

Direct leak of 7 byte(s) in 1 object(s) allocated from:

#0 0x49f22b in __interceptor_malloc

/home/gpg-user/Clang-3.5/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3

#1 0x4bc978 in xmalloc

/home/gpg-user/gcrypt-2.0-sanitize/libassuan-2.2.0/tests/./common.h:62:13

#2 0x2afdc8bddec4 in __libc_start_main

/build/buildd/eglibc-2.19/csu/libc-start.c:287

SUMMARY: AddressSanitizer: 3791 byte(s) leaked in 2 allocation(s).
FAIL: fdpassing

Attached is the script I am using to acceptance test the suite. It requires
Clang 3.5 (Clang 3.5 recipe was provided with Bug 1872).

Can you please lookup the description or the symbol for the ERRNO value 141 ?
find /usr/include -name errno.h | xargs grep 141
might reveal it.