doc/HACKING says it's OK to use variadic arg macros (from C99 features).
If it's OK, this patch can fix the initialization (which silences GCC 15 warnings):

Note that 1.53 was released today which fixes a small regression:

In case of build problems related to a failed test you may want to apply rEb6df311368133df90c3bf338fbf5c90bd8d950f8.

Fixed in: rE0f4fe2edf5e5: spawn: Care about closefrom/close call is interrupted.

@werner I read the code of gpgme/src/posix-io.c. I understand the two points:

• For the correctness sake, the possible interrupted closefrom should be handled.
• we can share the code with closefrom case and non-closefrom case.

@gniibe: Please see gpgme/src/posix-io.c where we have this:

Thank you for your report.

Fixed in rA69069bc63e6b: Remove an declaration for an unused function.

Hm, this might also be relevant in GnuPG's codebase in common/exechelp-posix.c, which contains a copy of the same code (licensed differently).

This problem has gone in libgpg-error 1.51, since the implementation doesn't use environ any more.

Fixed in 1.51, by introducing gpgrt_spawn_actions_set_env_rev, which assumes utf-8 encoding.

Fixed in 1.51.

Fixed in 1.51.

Thanks. Fixed in: rEd14c69a7f256: Avoid use of 'nullptr' for an identifier.

The C comittee is getting more an more absurd by adding new keywords. Breaking software for fun and funding. Workaround should be easy: Don't use the C23 option.

With the change, T7169 is fixed (by side-effect).

Pushed the change: rE1860f6407f83: spawn: Add new function to modify environment.

Thanks for opening a bug report. This is better for our workflow.

Replacing gpgrt_spawn_actions_set_environ by gpgrt_spawn_actions_set_envchange is not good, as it's exported and already used.

Here is my attempt:

Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3

Fixed GnuPG 2.4 in: rG730593affa91: common:w32: Don't expose unused functions.

libgpg-error fix is done in: rEc2a713fe11e3: w32:spawn: Remove unused function get_max_fds.

I'd vote for the second (utf-8) which is more aligned with our other APIs.

Since CreateProcessW allows two ways for lpEnvironment (one is ANSI environment block, another is Unicode environment block), if we want to support these two ways for users' of gpgrt spawn API, we would offer either:

I'm talking about CreateProcessW and how a user of gpgrt spawn API can specify lpEnvironment (when needed).

The environment is a property of the C runtime and well defined as a block of concatenated C-strings terminated by a zero length C-string. In case of wmain the C-strings use wchar_t and not char.

Please note that gpgrt_spawn_actions_set_envvars is W32 specific API in libgpg-error. Currently, the behavior with ASCII string is defined.
The patch is an answer in future if we want to extend the semantics supporting UTF-8.

String values are stored as UTF-16, but might not even contain a terminating doublezero since it can be any binary data. Note that on Windows the registry can be used to set environment variables. There "Edit binary data" shows exactly what is in the regkey. So if you use regedit with the String functions you can see that they are converted from latin1 to UTF-16.

The problem might be that we use getenv all over the place and don't specify the content. Frankly, it is not 100% clear to me whether the value of an enbvar need to be a string or can be arbitrary data sans nul? However, I can't remember that I ever wrote any code which did not assume ascii or utf8 for the value.

Here is my attempt:

Use of execve is better (avoiding use of environ).

Setting this to testing. Could be tested as described in https://dev.gnupg.org/T7188#188093 by verifying that the logged debug messages also use correct encoding.

Okay. Done in gpgme for gpgrt >= 1.51 (T7188).

Sounds like a good idea.

@werner Would it be okay to call gettext_use_utf8 (3) in gpgme's do_subsystem_inits where we currently call gettext_use_utf8 (1)? See https://dev.gnupg.org/source/gpgme/browse/master/src/version.c$77

Alright: Call gettext_use_utf8 (3) to set the current thread to utf8 and init all new threads to utf8 as well. This function with that value (actually bit 1 is relevant) can be used several times but it will never switch back the initialization to utf8. However, switching back and force to utf8 per threads is still possible.

Noticed this again that it was very slow. I guess how fast it is depends on your wine configuration. I worked it around by disabling winepath for me again. But do we want to change anything here or just move this to wontfix?

My summary here:

• Use of winepath by libtool is correct way for semi-hosted environment to run tests built by cross-build.
• (cross-)Build itself is possible with no winepath (or winepath -> /bin/false), if you don't need make check with semi-hosted environment.
• I don't see that it's too slow, these days. My environment is bookworm Debian (having Wine 8.0 something).

For me each time wine is upgraded I get for the first time an error when building something, but it is not slow anymore. Is this resolved?

Pushed the change: rGaf6c47b2910f: common,kbx,tests: Clean up the PIPE function API.

Using/setting a value of 2 would work for Kleopatra.

That is probably right for gpgme as used by kleopatra. However in gnupg we need to switch utf8 on and off.

The use of putc_unlocked has long been removed. So we should also remove the declaration. Normally this does not harm but in your case you may want to pass CFLAGS="-DHAVE_PUTC_UNLOCKED" to make or remove the above declaration.

Now also done for libksba.

See: MacPorts Ticket 70267 and MacPorts PR #24601

While the above patch worked for MacOS 10.8 and above, MacPorts CI shows a second error for older MacOS versions:

It looks like various flavors of BSD (including macOS just declare environ when needed): environ -- user environment Note: this is a very old MacOS X man page, however the current version is from 2003, and has the same Synopsis.

Didn't you had this problem with 1.10.x ? I can't remember that we changed anything at theat code for years. The only recent change was rC656ca459e which should not have changed anything. Maybe the problem is elsewhere.