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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, Feb 10
Wed, Feb 4
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.
Tue, Feb 3
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 ignore the npth_protect and npth_unprotect when calling fork to spawn a process.
New code in libgpg-error cares about npth_protect and npth_unprotect 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.
Fri, Jan 30
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.
Thu, Jan 29
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
Jan 9 2026
I think we won't fix that for 2.2