Alright.

Push the change as rE4a9def77488f: estream: Fix call to string filter for estream-printf..

I see your point: allocating STRINGBUF to make sure nul-terminated string.
The code itself doesn't work well in a test case of tests/t-prinntf.c, because it assumes string filter should be called with NULL for string.

Like this:

@@ -1196,10 +1196,25 @@ pr_string (estream_printf_out_t outfnc, void *outfncarg,
    future, when breaking API/ABI is OK, we can change signature of
    gpgrt_string_filter_t to have another argument for precision.  */
   int allow_non_nul_string = (arg->precision >= 0);
+  char *stringbuf = NULL;

We could also pass a nul terminated copy to the filter function in pr_string.

@item handling with @table has been pushed.

I learned about how @item is handled by TeX. By @table command, user specifies how to handle the item line. In the case of GnuPG, it is like:

@table @gnupgtabopt
@item --version
...
@item --help

(Emacs uses @table @samp, while GCC uses @table @gcctabopt.)
And @gnupgtabopt is a macro which is expanded to @code{\body\}

Possible approach for source texinfo files and yat2m would be:

I found a regression for @item --version; It emits \[en]version for roff.

Pushed my fix to support them.

I guess we should add an extended API to set the filter.

I guess we should follow the GNU standards and provide only info files ;-)

Other problems of yat2m transformation:
https://bugs.debian.org/1050886

Not easy do decide whether something is a PIN or a PUK and we will need to check a lot of places. So, not now.

I found a troff reference: https://www.quut.com/berlin/ms/troff.html

Ideally, we should change the source document to use @minus{} for a minus sign, and keep - only when it means a hyphen. But we cannot do that blindly; We need to handle it with care, in a way of case by case (Texinfo manual suggests no use of @minus{} with @code or @example, but it is needed for groff man pages in many cases).... We would need to consider each occurrence of - in our document. That's too much (if it were me to fix).

Pushed the change to:

• libgpg-error
• libassuan master
• libgcrypt master
• ntbtls
• npth
• libksba
• gpgme
• scute

It looks to me like it's marginally more common to *not* use the lib prefix for pkgconfig files:

I pushed the commit: rE64532db11fcd: build: New configure option --with-libtool-modification.

Pushed the change to libgpg-error.

That assumes that libtool won't change substantially as it did several times in the past and broke our cross compiling stuff. But as long as we keep the ltmain.sh in our repo and tarball the patch is okay because it better documents the chnages.

I learned that AC_CONFIG_COMMANDS macro can be used to improve the case of config.status.

How about the change like:

I have built it according to the method described here.
(https://wiki.documentfoundation.org/Development/BuildingOnWindows)

I wonder why you mention Visual Studio and Cygwin? Either it is Cygwin or a native Windows build.

Pushed to GnuPG master. Let us test. For my machine of Debian GNU/Linux, Wine emulation (Windows 32-bit, Windows 64-bit), make check goes all well.
After confirming the implementation, I'd like to put it into gpgrt.

I learned that Unix build environment needs Wine emulation (with winepath) for MinGW host (when uninstalled executable should run correctly).
https://www.gnu.org/software/libtool/manual/html_node/File-name-conversion.html

Fixed in 1.47.

Fixed in libgcrypt 1.10.2.

Fixed in libgpg-error 1.47.

Fixed in 1.10.2.

In T6388#168750, @gniibe wrote:

Thank you for the bug report.

I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.
[...]
That is, prefer possible_libdir1 when not used. Please test this.

I'll add new error codes to gpgrt

Any volunteers to write a manual? ;-)

The reason may be the following text/comment I found in gpgrt.texi:

This manual documents the Libgpg-error library application programming
interface (API). The goal is to that all functions and data types
provided by the library are explained. However, for now this is only
a stub and not very useful.

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

FWIW, some cards don't have PUKs but two PINs which are able to unblock reciprocal.

Should we also differentiate between wrong PUK and no PUK set?

Having GPG_ERR_BAD_PUK makes sense. So, I added a tag for gpg-error.

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

Ah, I had not done git pull for a week, and I didn't realize your patch.

I pushed a similar fix last week: rE885a287a57cf060b4c
and gnupg has a hack to fix it for oler libgpg-error versions.

Something like this should fix the behavior:

diff --git a/src/argparse.c b/src/argparse.c
index ef0c161..403c4a7 100644
--- a/src/argparse.c
+++ b/src/argparse.c
@@ -3000,7 +3000,13 @@ show_help (opttable_t *opts, unsigned int nopts, unsigned int flags)
         writestrings (0, "Options:", "\n", NULL);
       for (i=0; i < nopts; i++ )
         {
-          s = map_fixed_string (_( opts[ordtbl[i]].description ));
+          if ((opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER)
+              && opts[ordtbl[i]].description
+              && !*opts[ordtbl[i]].description)
+            /* It's empty header.  */
+            s = opts[ordtbl[i]].description;
+          else
+            s = map_fixed_string (_( opts[ordtbl[i]].description ));
           if ( s && *s== '@' && !s[1] ) /* Hide this line.  */
             continue;
           if ( s && (opts[ordtbl[i]].flags & ARGPARSE_OPT_HEADER))

AFAIU, gpgrt-config works well now for the multilib MinGW target.

Thanks !

A real fix will be in the next gpgrt release

On Windows, closing/inheriting handles is different to POSIX.
https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873
https://devblogs.microsoft.com/oldnewthing/20130426-00/?p=4543
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-deleteprocthreadattributelist

We should consider to break the Assuan API maybe we can do that without too many problems for the current use cases.

I'm going to use gnupg_process_* prefix for the functions.

Last two points are for future changes of assuan internal; For the case of controlling fds in detail, it is possible to use spawn callback controlling fds by the routine and let no-touching (inherit) by the spawn function.

I don't understand the last two points: This is only about the three standard descriptors but how shall we supply more descriptors? At least in GPGME we definitely need more.

Evaluating again, I'd like to change spawn functions like this one in libgpg-error:

Examining again, I realized that the current spawn API (not published yet, only available in libgpg-error master) is not that useful in general (or difficult to use), while it works somehow.

Here is the change of GnuPG to use new spawn functions from libgpg-error:

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.