Ah, I see what's up with the man page. It's documenting the Glibc getdents64() wrapper interface, so that's why it uses the Glibc types. But gpgme isn't using that wrapper, it's doing the syscall directly, so it should use the types the kernel uses, which as you've noticed are just generic unsigned and signed 64-bit integers, matching what my patch does.

/include/linux/dirent.h defines

struct linux_dirent64 {
	u64		d_ino;
	s64		d_off;
	unsigned short	d_reclen;
	unsigned char	d_type;
	char		d_name[];
};

In D600#6448, @ikloecker wrote:

$ man getdents64

getdents64()
    The  original  Linux getdents() system call did not handle large filesystems and large file offsets.  Consequently, Linux 2.4
    added getdents64(), with wider types for the d_ino and d_off fields.  In addition, getdents64() supports an  explicit  d_type
    field.

    The  getdents64()  system call is like getdents(), except that its second argument is a pointer to a buffer containing struc‐
    tures of the following type:

        struct linux_dirent64 {
            ino64_t        d_ino;    /* 64-bit inode number */
            off64_t        d_off;    /* 64-bit offset to next structure */
            unsigned short d_reclen; /* Size of this dirent */
            unsigned char  d_type;   /* File type */
            char           d_name[]; /* Filename (null-terminated) */
        };

$ man getdents64

getdents64()
    The  original  Linux getdents() system call did not handle large filesystems and large file offsets.  Consequently, Linux 2.4
    added getdents64(), with wider types for the d_ino and d_off fields.  In addition, getdents64() supports an  explicit  d_type
    field.

In D600#6445, @gniibe wrote:

If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.

Fixed in gpgme 1.21.0.

If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.

Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…

off64_t mat not the same as int64_t

Breaks them how?

In D600#6438, @werner wrote:

This breaks existing 32 bit systems with the 64 bit types.

This breaks existing 32 bit systems with the 64 bit types. Thus a test for off64_t is required which redefines it to int64_t if it does not exist.

Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.

It seems my eMails to gnupg-devel@gnupg.org do reach the list …

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

Oops. I closed the task accidentally.

Fixed (for GnuPG 2.4). I hope 2.2 prints the same status messages.

The General Error happens also when the PIN is blocked and no Pinentry opens.
As in this case, where the indicated "Generate New Keys" button was used on a blocked card.

Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

Thanks, that patch works for me.

We have discussed this yesterday. The idea/plan is to release the core library and the bindings as separate tarballs (created from the same repo) in the future.

This can be tested with Kleopatra by configuring an invalid keyserver and then updating an OpenPGP certificate.