New gpg-error.m4 detects gpgrt-config, too.
And configure supplies --libdir when it invokes gpgrt-config.
For other *.m4 (libassuan, ksba, libgcrypt, ntbtls), it is possible for them to check GPGRT_CONFIG to use gpgrt-config if any.
For npth.m4, it can do that too, with no hard dependency to libgpg-error.

A bit tricky, but this would be good to use gpgrt-config by gpg-error.m4.
I say "tricky", because its name is gpg-error.m4 but it configure GPGRT_CONFIG to access to GPG_ERROR_CONFIG.

It might be good idea to provide libgcrypt.pc in libgcrypt 1.8.x for forward compatibility with libgpg-error 1.33.

Well, I changed my mind. Use of new gpgrt-config requires software update to introduce gpgrt.m4 and update of configure.ac to switch gpgrt from gpg-error, in standard way.
That's too much this time. It's good to defer this change.

OK, I'll change to use gpgrt-config, along with requiring newer version of libgpg-error.

May I suggest to use a (new) gpgrt-config instead of the current name libgpg-error-config. The long term plan is to change the name of the library.

This is the dependency graph:

Thanks, that allowed npth to make successfully without the unsatisfied symbols.

Apparently, the check of sem_init function was not done (in config.log).
Could you please make sure to update npth/configure by npth/autogen.sh?

config.log is attached.

Could you please put the config.log of npth with the patch?
The intention of change is: we need to link -lpthread and -lrt

I tried with the updated patch, but I still see the same unsatisfied symbols during link. I verified that the patch was in place in configure.ac and also patched a clean version of configure.ac so that there would be only one instance of hpux in the case statement:

I realized that the test case is already there.
I'm not sure the reason why make check for npth works well on HP-UX (before the my patch). It uses npth_attr_init (hence, pthread_attr_init) in tests/t-thread.c.
Perhaps, libtool is clever enough to detect -lpthread into src/libnpth.la (dependency_libs), I suppose.

Thanks for your testing, it's near. Here is updated patch:

Rebuilding npth results in three unsatisfied symbols:

Thanks for config.log of GnuPG. I think that I located the problem; While gpg-agent should be linked to -lpthread, it was not. The configure variable NPTH_LIBS in config.log doesn't have -lpthread. Thus, pthread_* are linked to the ones of stub, and it resulted the error.

I have uploaded config.log. Let me know if you need any additional information/files. Thanks!

Thanks for quick feedback.
Yes, it is a build problem, which should be handled by configure + make.
Could you please upload the build log here, so that I can check it to fix configure.ac+Makefile.am?

Thanks. That appears to be the exact issue. I was able to get around it with export LD_PRELOAD as indicated in the man page. Any ideas on how to address it in the make? This is what I see when I do an ldd on gpg-agent:

ENOSYS means it's linked to stub.
http://nixdoc.net/man-pages/HP-UX/man5/pthread_stubs.5.html
Somehow the build process may be wrong for the gpg-agent executable.

That comes directly from pthread_attr_init - need to check what's special on HP/UX here.

Add the tag of npth (forgotten).

From my viewpoint, it works well. Just you don't have a permission to install the library to the directory.

Indeed. Van is a wonderful person.

Nice talk, just watched it.

In T3206#99005, @werner wrote:

1.4 has build fixes for NetBSD. Thus I _assume_ this bug has been fixed.

@aa can you please try npth 1.5 ?

For me, it works. Please re-open if you still have any issue for NetBSD.

1.4 has build fixes for NetBSD. Thus I _assume_ this bug has been fixed.

Fixed in npth 1.4.

Fixed in npth 1.4.

Fixed in npth 1.4.

I added an npth_is_protected function which is sometimes useful for debugging.
I also changed the license to LGPLv2+.

@werner Oops, sorry.

That's me with the key

I confirmed that mingw-w64 version 1.0 defines timespec.
So, for older versions of mingw-w64, we need a fix to avoid errors.
But, your suggestion of __MINGW32__ != 1 seems wrong to me (I think it is always defined as 1).

Err... npth repo is not yet added under dev.gnupg.org.
I requested as T3064.

Thank you. I just tried:

autoreconf -fiv && ./configure && make && make check
...
Making check in src
Making check in tests
make  check-TESTS
PASS: t-mutex
PASS: t-thread
PASS: t-fork
==================
All 3 tests passed
==================

on NetBSD-7.99.67/amd64.

git://git.gnupg.org/npth.git

Thanks for working on this.
I can't seem to find a link to the repository for testing, can you please point me in the right direction?

I found that FreeBSD also requires -lpthread thing. I also commit the change to the repo.
Tested with FreeBSD 11.0.
I think that TrueOS can be considered as FreeBSD variant.

Fixed in the repo for DragonFlyBSD 4.8 too.

In T2998, NetBSD was fixed.
I'll check for DragonFlyBSD.
IIUC, FreeBSD and OpenBSD has no issue.

It works for me on NetBSD 7.1. Please test.

I tested with NetBSD 7.1 and -lrt is not required.
Nevertheless, it would be required for older NetBSD, so I leave -lrt check for NetBSD.
I'm going to push the change of D415 now.

Could you please look at https://dev.gnupg.org/T2998 ?

I think that NetBSD also defines single thread version of pthread_* functions in
libc.
How about attached patch in configure.ac?
(You need to generate configure)

D415: 990_npth-netbsd-20170328.diff

It seems that -lrt is required on NetBSD.

Oh yes, then we should include NetBSD at least into the nPth and libgpg-error
builds.

NetBSD has its own pthread library (different from OpenBSD and FreeBSD), so I
think this would be a good idea.

Our jenkins has no problems building nPth for OpenBSD 6.0.
wiz: Do you think that NetBSD (x86 I assume) is much different than OpenBSD so
that we would benefit from adding NetBSD to our Jenkins builds?

gniibe: Do you have time to look into this?

Fixed in 1.3.

Indeed, I confirm that the newly updated version 2.1.16 fix this issue, thanks a
lot for doing this portability work!

It has been confirmed that 2.1.16 solves the problem.

The reason for the crash is that 2.1.15 is calling gpgrt_set_syscall_clamp
before nPth is initialized. The nPth initialization was changed in 2.1.15 so to
solve problems on some other platforms.

uldis: Thanks for your comment. Let me show my opinion.
There are three ways (at least) to create a semaphore.
Each has different semantics, how it can be shared among different processes.

(1) sem_init with pshared=0: Not shared among processes
(2) sem_init with pshared=1: Shared among children processes of particular parent
(3) sem_open: Shared among any processes (with relevant permission)

For AIX, npth doesn't work well with (1). You suggested (3), while I proposed (2).
It is true that (2) and (3) would open up some attack vector(s),
but I believe that (2) is smaller, if any.