Page MenuHome GnuPG

AM_PATH_GPGME_PTHREAD not ready for gpgrt-config transition
Closed, ResolvedPublic

Description

Hello,

AM_PATH_GPGME_PTHREAD does not seem to be ready for the transion to gpgrt.
Afaict it tries to invoke gpgrt-config ... gpgme --thread=pthread
which gpgrt rejects, since --thread is not a valid option.

Texinfo docs says

AM_PATH_GPGME_PTHREAD checks for the version of GPGME that can be used with the native pthread implementation, and defines GPGME_PTHREAD_CFLAGS and GPGME_PTHREAD_LIBS. Since version 1.8.0 this is no longer required to GPGME_PTHREAD as GPGME itself is thread safe.

I guess the latter sentence should read "Since version 1.8.0 it is no longer necessary to use AM_PATH_GPGME_PTHREAD as GPGME itself is thread safe, and regular AM_PATH_GPGME can be used instead."

Assuming my guess is correct, and given that 1.8.0 was released more than 6 years ago it should be safe to either make AM_PATH_GPGME_PTHREAD a synonym for AM_PATH_GPGME (perhaps with deprecation warning?) or drop it altogether.

cu Andreas

Details

Version
1.18.0

Event Timeline

gniibe triaged this task as High priority.

Thank you for the bug report and your suggestion.

Yes, AM_PATH_GPGME_PTHREAD should be deprecated and we should handle it as a synonym for AM_PATH_GPGME.

After the GNU C library 2.34 (libpthread, libdl, libutil, etc. integrated to libc), now, adding -lpthread at link time makes no sense.

gniibe changed the task status from Open to Testing.Nov 29 2022, 3:20 AM

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Works for me (testcase: ostree 2022.6-1), shows a warning on autoreconf (but not on ./configure). Thank you!

cu Andreas