Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

And the arm64 cross-compiler:

Sorry, I forgot to mention that Apple ships a gcc-wrapper for clang. It just accepts gcc command lines parameters and translates them to clang parameters.
Here is the output of gcc --version:

You say that you build using clang but the log shows that you invoke gcc.

The problem is meanwhile solved. Thanks a lot
Heinrich

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

This has been fixed for Unix on 2.2 and 2.3. The command line fix for Windows is a larger thing already tracked by T4398.

We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.

Finally, with the physical device, I figure out what's going on.
The error handling in bulk_in in ccid-driver.c is not good for pinpad input.
It doesn't return an error when it is cancelled or timeout (for the user interaction).
And it calls libusb_clear_hald which causes screwed up situation.

Recall that each user has their own keys and configuration. This seems to be a general question on how to use GpgOL. Please use the help resources listed at gpg4win.org instead of this bug tracker.

You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.

I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000

If you mean OpenPGP Card v3 standard, no it did not support cv25519 ed25519, but some other curves up until v3.4. So if there is a specific specification bringing this feature, can you might refer to the specific version? Otherwise, I think this task is still valid.
I remember the problem being the card manufacturers that are not interesting in cv25519 (yet).

Or it might be related issue of name server access like in T3168: dirmngr: gpg: keyserver receive failed: No keyserver available.

As of November 2020, the redirect problem has gone.
And we addressed that as "Legacy GnuPG MiniHOWTO" in rDd51cd2013e66: web: Add warning notes to most HOWTOS..

This must be an issue of SRV record retrieval.
Merging.

Support was added in version 3 card.

Because the original problem of EAFNOSUPPORT has been fixed, I am going to close this bug.

It is likely that EPERM (Operation not permitted) occurs by a system call connect(2) if you have some firewall rule(s) which forbids network access.
The dirmngr use libdns resolver which directly connects name servers.
If this is the case, you can use `--standard-resolver\ to use system's standard DNS resolver instead.

The log file specified in .gnupg/dirmngr.conf is created at the start of dirmngr.
dirmngr is invokded by the first call of gpg, and it keeps running and handle next request from second invocation of gpg.
So, nothing is problem.

On Debian, please see: /usr/share/doc/g++-mingw-w64-i686-win32/README.Debian

IIUC, the error occurred when Kleo is exiting and a destructor (in libKF5ConfigWidgets) is called with null pointer.

Version 3.1.14 released 2020-11-25
Kleopatra / GnuPG: Unicode home directories are now supported. (T5055)

Fixed in rDf810f0bc5b13: git.gnupg.org: Update entry page.

For ctx->exportPublicKeys returning 0 even when a failure, (with fix of gpg) error handling should be done differently.

Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..

Well, I fixed my loopback passphrase provider and the application no longer crashes with a bad passphrase.

Right that description sounds like it is ~20 years old ;-)

Will be fixed with 3.1.14

Works, I've tested with Kleopatra.

relatively new feature

Yes. In the mean time, I'm using a cheap workaround : validate the input passphrase by signing a dummy text before exporting. Not that ugly and can stay for long.

For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..

Fixed in rG006944b856ee: scd,nks: Fix SEGV for learn for older card..

Great. Please apply the patch.