How did you configure? If possible, please show us the configure options when you built.
Did it work in older version(s) of libgpg-error?

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

• first manual gpg -K and gpgsm -K displays the correct output now
• the loop ran without a hang for 50 times

It should be solved by the upstream (libtool, gnulib, and possibly autoconf/automake). The solution would be refactoring AC_PROG_LD and AC_LIB_PROG_LD factoring out common things like handling use of GNU LD.

Fixed in libgpg-error 1.59.

Investigating GNU ld, I learned that there is no easy way (~= no way) to suppress the warnings (other than 2>/dev/null). It was implemented by the special section named gnu.warning.SYM where SYM is a symbol. I think that this is not-so-good for glibc to notify its users about possible static link problem, by gnu.warning.SYM.

I found two issues in libgpg-error for spawning functions.

POSIX documentation never says that PSHARED=0 prevents sharing among processes. In my opinion, it still conforms to POSIX even when a PSHARED=0 semaphore can be shared between parent and child processes.

I've tried the new patch in my environment, and it fixes the gnupg HEAD self tests as well. Thank you!

In tests/migrations, (unlike tests/openpgp and tests/cms), the tests do not prepare gpg-agent, but it is gpg which invokes gpg-agent if needed.
Because of that, on NetBSD (where POSIX semaphore has a different semantics), it hangs with gpg --list-secret-key, when gpg tries to spawn the gpg-agent process.
In the old code of 2.4, it simply ignores about the npth_protect and npth_unprotect sequence when calling fork to spawn a process.
New code in libgpg-error cares about npth_protect and npth_unprotect sequence but it was not sufficient; We need to care about NetBSD's semantics. Child process should not call npth_protect. With shared semantics, child process's calling npth_protect affects to cause parent process: it hangs.

TL;DR
This ticket was created because building static-linked gpgv shows warnings from glibc for getpwnam and getpwuid.
Basically, we can/should ignore the warnings from glibc at link time (for normal use cases), because it is irrelevant.

Let us mark this as a feature requests. gepwnam(3) is a standard libc function and if glibc does not support it; this is more likely a glibc bug than a bug in an application.

It seems this broke the self tests (and gpgme, and notmuch) on NetBSD: https://dev.gnupg.org/T8065

I think we won't fix that for 2.2

gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way:

@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

Scute fixed in rSc3dc9c581631: w32: Use CSIDL_COMMON_APPDATA if available.

Okay, forward porting that patch is the easiest solution. Actually this is not enough: Users of Libgcrypt also need to make sure that the new sysconfig dir has the right permissions. That's a part for the installer and concrete ACLs may differ.

I examined the code of gnupg_sysconfdir in gnupg/common/homedir.c, if we could factor out things to gpgrt, so that something like gpgrt_fconcat with GPGRT_SYSCONFDIR can be implemented.

For GnuPG, applied the change to master: rG57affc4e98ab: common,agent,dirmngr,kbx:w32: Synchronous spawning daemon process.

I checked the code under gnupg/dirmngr. Those are no harm.

I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.

For gpgrt/argparse this could be an option (to remove hard-coded /etc):