On Mac OS X 10.5.8, PPC Leopard, it built with the patch, gpg-agent works.

Thank you for your quick testing.

I've reported the success to MacPorts. My test was performed on only one platform, Mac OS X 10.4.11 or "Tiger". Since there exists a problem with building recent version of GPGME testing on Mac OS X 10.5.8 or "Leopard" will have to wait a few days…

With the unified patch all works fine (again), even the test target succeeds!

Performing the patch manually the "port" (package) built and installed. Starting then gpg-agent worked too, killing it (with gpgconf) worked as well.

The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.

Apply the change in: rPTH417abd56fd7b: Fix INSERT_EXPOSE_RWLOCK_API for musl C library.

@gniibe Thank you very much! That works.

@thesamesam Thank you for the report.

This seems to have regressed musl support, per https://bugs.gentoo.org/925443.

Fixed in npth 1.7.

The patch is part of 1.7 - please test and in case of problems feel free to re-open.

After applying patch to nPth 1.6 no semaphore leaks detected. Tested with GnuPG-2.3.3.
There has been positive feedback from production environment as well.

npth_t is untouched for Windows 64-bit.

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

Thank you.

Indeed, different versions of MinGW use different symbols to guard the declaration, and using those symbols in not future-proof enough, IME.
Removing the declaration is definitely the best solution.

Pushed the change removing the definition.

In T5889#156302, @gniibe wrote:

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. I understand the situation by looking at mingwrt-5.4.2-mingw32-src.tar.xz.

The version of MinGW is 5.4.x, the latest one. It is available from https://osdn.net/projects/mingw/releases.
MinGW64 is a fork of the above (original) MinGW. They have unfortunately diverged, thus the need to have these changes.