For the spawn_cb, I reconsider. Having three calls complicates use, and it is actually not needed. In the case of pthread_atfork, it is needed, because fork may be used deeply in some functions. In our use cases of spawn function, prepare part of the callback can be called before calling spawn, and parent part of the callback can be called after calling spawn.

I decide use of pid_t, as there are different semantics between POSIX and Windows, *and* there is a problem of MinGW-w64. I introduce gpgrt_process_t, instead.

Another thing when we define a type which represents process.
For pid_t, MinGW-w64 has a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1397787 (or https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1456671365-21759-1-git-send-email-sw%40weilnetz.de/).
(1) GetCurrentProcessId always returns 32-bit (DWORD), so, it can be represented in 32-bit (although DWORD is unsigned).
(2) POSIX requires pid_t should be signed integer https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
(3) Original MinGW defines pid_t as int (in include/sys/type.h by _pid_t). (checked in mingwrt-5.4.2)

@werner - having another argument might be useful. Indeed, pthread_atfork has three callback functions as its arguments (prepare, parent, and child).

I general I agree.

To have clear semantics, I propose a change to gpgrt_spawn_process_fd (calling SPAWN_CB, instead of AFTER_FORK_CB, and give it return value), and exporting gpgrt_close_all_fds to users.

By the commit rE43c1e85fe29a: spawn: Expose spawn functions., spawn functions are exposed now. The API is compatible to the one of internal functions in GnuPG master (2.3).
Semantics is not well-defined portably for:

• gpgrt_spawn_process: EXCEPT only makes sense in POSIX. User could expect that the API does closing all fds except fds specified by EXCEPT in POSIX.
• gpgrt_spawn_process_fd: AFTER_FORK_CB only makes sense in POSIX. User could specify the callback so that it can control sigmask, envvar, open/close/dup-ing file descriptors, making sure releasing some resources beforehand, etc.

Thank you. I am glad that it is already resolved.

Will this be in the next release of libgcrypt?

Okay. So, I removed gpg-error-config, updated libgcrypt/m4/gpg-error.m4, and then rebuilt configure. And, gcrypt configures and builds.

Thank you for the information.

Actually, it looks as if libgpg-error-1.46 already has that fix.

Thank you for your quick reply.

Yes, it is on macOS.

From the information in gpg-error.pc, I think it's on macOS.

I see. I understand the use cases for POSIX to keep some file descriptors.

without this list we don't have an option to keep file descriptors open; its not just stderr but for example log files and descriptors which pare passed by other meands than libassuan functions.

• assuan_pipe_connect and internal _assuan_spawn

Thank you for your report. IIUC, your log is the build log of GnuPG 2.2, so, I put the tag "gnupg (gpg22)".

Fixed in libgpg-error 1.46 and pinentry 1.2.1.

Checking musl internal, it seems that we can detect a single threaded application by:
https://git.musl-libc.org/cgit/musl/tree/src/internal/libc.h#n22

Standard behaviour for stdio functions.

Thanks, I really appreciate having this fixed in gpgrt-config! I backported the commit to gentoo and can confirm that fixes the build issue with slibtool.

I pushed the changes. It also cares about the case for --cflags.

Push the change.

Fixed in master.

@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.

@werner For what it's worth, I would like to apologize for my rudeness and disrespect. I had a quite convoluted notion of what the development process entailed. In particular, I was ignorant of the different and opposing responsibilities and the separation of concerns involved in the development process. In retrospect, there were at least a dozen different ways in which this could/should have been handled and all of them are downstream.

Applied the changes to master.

Fixed in libgpg-error.

libgpg-error 1.45 is out with the fix.

Thank you for the error output.

This is with mingw.org's MinGW, version 5.4.x.

Please specify your MinGW version.

@gniibe Thanks a bunch for the quick fix!

Pushed the change in rE433aba9e778e: build,tests: Fix detection of have_lock_optimization..

@marv Thank you for your report.

Hey gniibe,

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.