thanks, looks good!

Thank you, applied.

Thanks for looking into this, @gniibe! over on https://bugs.debian.org/1003313 Helmut is asking for a re-consideration because he wanted to match arm-linux-musleabihf. Would you be ok with a change like my proposal rE371d1c952297f781277b979a4662859ec80fe836 (on branch dkg/expand-musl), that expands *-*-linux-musl to *-*-linux-musl* ?

The primary version of that script is in libgpg-error. Thus it needs to be fixed therefirst.

Thank you, @gniibe ! i'm applying your change to the debian packaging as 1.43-2. i'll let you know if it doesn't satisfy the folks trying to crossbuild debian on top of musl.

Thank you for forwarding from Debian.

The patch worked, thank you very much.

The patch worked, thank you very much.

Thank you for the log.

Here is the log file requested.

Let me explain concretely.

Excuse me NIBE san. What if any action do you expect me to take on this matter?
__outer

Thank you, applied.

The original intention was to fix t-poll failure on Windows.
It was fixed in different way in rE858bcd4343ac: tests,w32: Use CreatePipe and es_sysopen..

Thanks for the help. After running make clean / aclocal / autoconf / autoupdate … &etc, the patch worked & make check passed all eleven 11 tests, ie the new 12th test was not performed.

Thank you for your log.

Here is ”config.log", or did you want just the screen output?

Please show us the log of configure, not just the result of the failure.

I’m not that geeky anymore.

If you see wrong result for the decision of the HAVE_LOCK_OPTIMIZATION (for running the test), it's better to contribute to gnulib (https://www.gnu.org/software/gnulib/) for the detection of thread features.

I've just confirmed that the fixes in the commit "rE50e0f32b1935" above to configure.ca & tests/makefile.am do NOT fix the problem under MacOSX Catalina 10.15.7 using Xcode 12.4, gcc Apple clang-1200.0.32.28.

I'm getting the same error even when compiling with x86_64/glibc (from Apple clang-1200.0.32.28) :(

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.