Reading the documentation of musl, it seems that there are no equivalent feature which detects if an application is single-threaded or not.

In the libgpg-error implementation, it may skip synchronization when it can detect an application is single threaded. The t-lock-single-thread test checks if it really skips as intended.

I do not think that we should put any more support for FDs into gpgrt. The goal is to move entirely to the Win32 API.

I don't know how runtime (of mingw) is thread-safe, but if it is, it should work well.

Also, and I should maybe have opened with it, the issues vcpkg has with your build system are currently tracked here, while my effort to build gpg-error natively (i.e. without relying on ShiftMediaProject fork) on all platforms is here.

In T5365#151844, @gniibe wrote:

Let me clarify the use case of gpg-error.m4.

gpg-error.m4 is for GnuPG and its friends, where we cannot assume availability of pkg-config. Its capability is limited, and we don't pursue 100% compatibility of pkg-config.

Let me clarify the use case of gpg-error.m4.

In T5365#144688, @gniibe wrote:

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

Also applied to gpgme.

Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.

For libgcrypt, it was fixed in: T5637: Use poll for libgcrypt (support more than 1024 fds)

Hi, was there any update on this? I found the following bug [0] in libgcrypt, which we solved [1] with using poll ages ago.

These are great news. Thank you!

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:

That does indeed not look like something which could introduce a regression.

I misunderstood as if we need to update libtool from upstream.

macOS has low priority for us and I do not want to risk any regression.

About merging our local changes.

We have our own changes for ltmain.sh and libtool.m4.

And update from automake 1.16:

It's better to update the set of files from libtool:

build-aux/ltmain.sh
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4

Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/link_all_deplibs.patch
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/netbsdelf.patch

The fix works for me (using bash on openSUSE Tumbleweed).

Here is a possible fix:

Added a test, and tested with glibc 2.32 by manual editing config.h for USE_POSIX_THREADS_FROM_LIBC.
Works correctly.

Actually, I think there's a way to make gpg_strerror_r more usable on its own. I previously said

I find it quite difficult to use strerror_r and gpg_strerror_r. With having to guess and retry to get an appropriate buffer length, a wrapper which dynamically allocates the string seems to be needed.

Here is the documentation of the new way of single-threaded execution:
https://www.gnu.org/software/libc/manual/html_node/Single_002dThreaded.html

We also need to update m4/threadlib.m4.
Now, it's maintained in gnulib.
See the changes in:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=12b5b00f93c6433c3df8176fc9674d7600f8b268

Applied and pushed.

(sorry, about my former comment, I only now realized that you did just that already in your original patch)

Updated:

diff --git a/configure.ac b/configure.ac
index 53a343b..f496729 100644
--- a/configure.ac
+++ b/configure.ac
@@ -82,6 +82,7 @@ AC_PROG_AWK
 AC_CHECK_TOOL(AR, ar, :)
 AC_USE_SYSTEM_EXTENSIONS

I guess the strcasecmp (nl_langinfo (CODESET), "UTF-8") results in some overhead, so if we do that what about kicking in only if a truncation is really to happen.

Thank you for your publishing your key of CB6BE1D0D7D1594A.
I applied and pushed your changes.

Thanks. Note, that the same code is in gnupg2 in common/exechelp-posix.c:736

In T5381#144927, @gniibe wrote:

For gpgrt_wait_processes, I modified it to skip invalid PID.
The change is: rE956c40f106ea: core: Fix gpgrt_wait_processes, by skipping invalid PID.

For gpgrt_wait_processes, I modified it to skip invalid PID.
The change is: rE956c40f106ea: core: Fix gpgrt_wait_processes, by skipping invalid PID.

Thanks. I understand that this is no big issue in the test code, but half of the code paths have proper cleaning already so fixing it once should save anyone in the future going through the same issues over and over again during our releases or anyone else who would run your code through static analyzer.

Thank you.
For get_attr_l, I pushed a fix as rE89a353f418f5: build: Fix gpgrt-config for handling 'Requires' field.

Actually I don't care about releasing resources for regression test failures.
The other missing free is for code which is commented out (#if 0) but should eventually be fixed.

Fixed in 1.42.

I was wrong in my last comment. Escaping by another \ is needed.

A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).

@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).

Or, if we keep the code of newline (so that it will eventually support path with a space in future):

Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.

@gniibe OK, so... "worst case": I guess this worked? ;P

@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(

@gniibe Ah yeah, that was the commit I meant to reference when I said "--maybe caused by --", but then forgot to go back and fill in the commit hash ;P.

I wonder if this works in your use case:

diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4
index d910754e..aeedaf10 100644
--- a/m4/gpg-error.m4
+++ b/m4/gpg-error.m4
@@ -65,7 +65,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
   min_gpg_error_version=ifelse([$1], ,1.33,$1)
   ok=no

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

(To be clear, I also know enough about autoconf to not have been like, blocked from upgrading by this: overriding ac_cv_path_GPGRT_CONFIG worked, but I can't believe that's the intended way for someone to ensure they get the correct path for gpgrt-config ;P.)

@gniibe The problem is that the check seems to just find gpgrt-config from the path; like, I'm already passing --prefix and --host, but it is deciding to just arbitrarily pick up my system-wide copy of /usr/local/bin/gpgrt-config. Here's my entire configure invocation from that earlier failed build: note that the --prefix is the same as --with-gpg-error-prefix.

We are in transition from old gpg-error-config to new gpgrt-config. <-- This is the cause, while I tried to cover most use cases.

Pushed the change. Please test.

See the comment in rE13918d05a333: Allow building with --disable-threads. for ABI incompatibility.

When building with no threads support, I think that generating same lock-obj-pub-$host.h is just possible by this change.

Tell us the architecture(s) which doesn't support POSIX threads by uClibc.
Adding support for such an architecture would be the best.

Sorry, I was assuming uClibc were not supporting POSIX threads.

Thank you for more information.

I was not the author of the host "hacking" which has been committed to buildroot in 2016 by https://git.buildroot.net/buildroot/commit/package/?id=2f89476ad98b82ea9f914337b0050c4808082c82 so I can't really comment on it.
You can find more information here: https://patchwork.ozlabs.org/project/buildroot/patch/1451762923-15985-1-git-send-email-joerg.krause@embedded.rocks/
Especially, it seems that Jörg Krause started a discussion about this issue and proposed a patch to fix the architecture depends but it was never applied. Unfortunately, I wasn't able to find more information as it seems that links on comments.gmane.org are broken ...