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.

The optimization introduced for curve 25519 and curve 448 en-bugged for usage of direct MPI.

Guys, no offense, but you screwed things up a lot.
You should have put some warning within installer 3.1.15 when it updates files, or at least make an error message more verbose.
Right now it is totally not obvious what to do (move from where to where{F2234144}) except for rolling back to previous version of Kleopatra.
For example, I a PC user with administrator account only (and it will remain forever), so?

Yet another identify theft scam committed by clang.

This patch should work if configure properly detects need for extra underscore on C symbols:

This patch should work if configure properly detects need for extra underscore on C symbols:

Please look at the code:

Sorry to dig up an old report...

Sorry to dig up an old thread...

Here's the patch I am using for the Apple M1: libgcrypt-darwin.patch. The patch is public domain so anyone is free to use it.

This is kind of a hack, but this patch:

yep, Should be fixed in libgpg-error/src/w32-gettext.c unless we want a way to retrieve the meat data. We can also and faster fix this in gnupg proper.

Hey @wener.. As I mentioned in the original post, there's a default-new-key-algo setting... Is it still not possible to use specify something like "rsa4096/cert,rsa4096/encr,rsa4096/sign,rsa4096/auth"?? Would love to see some progress on this. Glad to help test.

--clearsign may only be used for plain text documents due to line ending conversion etc.

Looks good to me, it no longer returns immediately with the error when there are no readers and the command itself seems to work. Thanks.

It's OK not supporting generation in PostScript format.
Thus, we can remove image_eps support.
Then, convert is not required any more.

I noticed that my windows user folder contains Chinese character, and I rename that into English and seems like kleopatra works fine. GnuPG in cli cannot show Chinese folder name properly, thus I guess that's the reason why kleopatra exits without showing a gui.

Ah, I see that when there is no card reader, it returns "Service is not running" with PC/SC.
Let's fix that.

Thanks! Tested the above patches and now all the tests pass on the machine where I saw the failures.

Thanks for the report.

Example from gpg.c:

ARGPARSE_s_n (oQuiet,	  "quiet",   N_("be somewhat more quiet")),
[...]
ARGPARSE_s_n (oNoGreeting, "no-greeting", "@"),

The quiet option has a human readable description, but the no-greeting option does not have one. Consequently, gpgconf --list-options gpg gives the following result:

[...]
quiet:0:0:be somewhat more quiet:0:0::::
no-greeting:0:3::0:0::::1
[...]

For comparison, on an English Linux system the options also look wrong, i.e. all options that are problematic in the German translation are "raw" option names enclosed in double quotes. It seems that the untranslated description of the options is already missing.

Yes, I think the service not active is the cause of the issue. But I don't really understand where this error is lost, I think this should be investigated because I would also expect it not to have a success on this line:
[3900] org.kde.pim.kleopatra: DeviceInfoWatcher::Worker::poll: context finished with Erfolg (code: 0, source: Quelle nicht angegeben)