It seems that nl_langinfo(CODESET) returns US-ASCII on your system.

Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.

Some information of Qt5 about -fpic:

• https://lists.qt-project.org/pipermail/development/2015-May/021557.html
• https://bugzilla.redhat.com/show_bug.cgi?id=1700435

Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400

Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.

I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.

Thanks for your report.

Last week:

• Applied changing UI of GnuPG master "cv448" to specify X448 to align to cv25519
• Pushed Ed448 support in GnuPG: D505: Ed448 support for GnuPG
• Chopstx 2.0 with RISC-V core support

This week:

• More change of UI of GnuPG is needed, like Ed25519/Curve25519 pair
• I took T4977: dirmngr not working with linux kernel parameter ipv6.disable=1
  • but I don't know the reason why the reporter said : "dirmngr stops working properly."
• Somehow related, I am going to use IPv6 at work this week (IPv6 + IPv4overIPv6).
  • In Japan, AAAA filtering of DNS by ISP used to be common (2012-2017).
• Learn Happy Eyeballs: https://tools.ietf.org/html/rfc8305

When I test it on Debian, disabling by,

Please get log of dirmngr, by putting

log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log

I think the feature is not (yet) supported on Windows.
Please see: T3883: Add Win32-OpenSSH support to gpg-agent's ssh-agent

Pushed to master as rGa763bb2580b0: gpg,agent: Support Ed448 signing..

Update to [rGc94eea15d}.
Hash defaults to SHA512.

Last week:

• Pushed the change for Ed448 to libgcrypt (no optimization at all): D504: ECC change for Ed448
• Created (and updated) the change for Ed448 to GnuPG: D505: Ed448 support for GnuPG
• Minor clean up in GnuPG to prepare accepting D505
• Tested OpenPGP card v3.4 implementation by Achim
  • flashing was done successfully with TTXS reader
  • no problem with current GnuPG
  • tested against Gnuk's test suite
  • found a minor difference: In V3.4, SEX DO factory setting is '0' (Unknown), while it used to be '9' (N/A)
    • ISO/IEC 5218 thing
    • I don't know if we need to modify GnuPG or not

This week:

• Change UI of GnuPG master "cv448" to specify X448 to align to cv25519
• Others: FSIJ accounting of FY2019 and AGM 2020

D505:

• I realized that the patch number looks like "SOS" :-)
• For "Ed25519", libgcrypt supports ECDSA as well as EdDSA
  • And Gnunet looks like using it (I don't know if it's intended or not)
  • I don't know if it works well, I'm afraid cofactor matters
  • but for "Ed448", ECDSA is not supported
  • Anyway, because of this, a key or sig-data with Ed25519 curve for EdDSA has "(flags eddsa)"
• Learning math for elliptic integral and Jacobi elliptic functions

(1) Has no (flags eddsa) in key in SEXP.
(2) Has no (flags eddsa) and no (hash-algo shake256) in data to be signed in SEXP.
(3) Has no (flags eddsa) and no (hash-algo shake256) in data to be verified in SEXP.
(4) Uses SHA256 for hashing of OpenPGP data

Update to rG4bdade5b0bea: agent: Use get_pk_algo_from_key.

The changes just follow the existing practice of Ed25519, which does:

Changes pushed to master.

Last week:

• GnuPG change D502: ECC change for SOS pushed to support X448 encryption
  • Thanks @werner for backporting rC47e8977d24e5: mpi: Fix flags in mpi_copy for opaque MPI. to libgcrypt 1.8 and rGeeb599c9e261: gpg: Fix for new SOS changes when used with Libgcrypt < 1.8.6.
• Wrote D504: ECC change for Ed448 for libgcrypt to support Ed448
• Got new BasicCard and did mistake to clear its EEPROM
• libgpg-error cross build: T4973: Cross build problem with v1.38

This week:

• Consider/test adding Ed448 to GnuPG
  • with change of use of "cv448" in current UI from "x448", too
• Test again with new image for OpenPGP 3.4 specification

Pushed the patch to master.

It's me who should say "thank you".

Or one liner patch would be enough:

IIUC, you build libgpg-error with setting PKG_CONFIG_SYSROOT_DIR.
It results errors, because while old gpg-error-config never supports PKG_CONFIG_SYSROOT_DIR, it compares result from old gpg-error-config and gpgrt-config gpg-error.

Please give us full build log here, so that we can investigate what's going on. You can upload log file by the "upload" button in comment edit dialog.

Sorry for repeated mistake of mine.
I fixed it and tested with 'make distcheck' in the environment of cross-build for ppc64el host.

Thanks for your report. I think it fails to generate src/lock-obj-pub.native.h.

Last week:

• Fix libgpg-error cross build probrem
• Pushed gpg-agent better support to SOS for X448
• Created D502: ECC change for SOS

This week:

• X448 with SOS

I was wrong. This patch itself doesn't require libgcrypt 1.9. It works with libgcrypt 1.8 well.

I think that the changes for ECC I've done matters:
o rC050e0b4accfa: pubkey: Support a method to get data as an opaque MPI.
o rC05a7d2f262bc: ecc: Support an opaque MPI handling in mpi_from_keyparam.
rC3d5a05767b84: ecc: Fix handling of point representation in EdDSA.
o rC8fce1027c253: ecc: Return an opaque MPI by _gcry_ecc_ec2os.
rC35c1faaea2b0: ecc: String constant fix.
rCad8927f40169: ecc: Simplify _gcry_ecc_compute_public.
o rCc5a7191c1bd1: ecc: Use opaque MPI for _gcry_ecc_mul_point.
rCbbe15758c893: ecc: Fix _gcry_ecc_mont_decodepoint for data by old implementation.
rC27e848666b4a: ecc: ECDH clean up for use of ec->nbits.
rC82441bbb8290: ecc: Fix key generation for ECDH.
rC6d93812aa312: ecc: Fix debug output.
rC6a30a9a2cc48: ecc: Simplify using mpi_ec_t directly.
rC975de3879691: ecc: Fix for NBITS support.
rCe921ad5b3ad0: ecc: Add NAME member to struct mpi_ec_ctx_s.
rC488704be6e04: ecc: Add key generation support to mpi_ec_get_elliptic_curve.
rC5415bc578080: ecc: Consolidate with _gcry_mpi_ec_internal_new.
rCc2aa333dd88b: ecc: Support flags and debug print in _gcry_mpi_ec_internal_new.
rCc7b97ac9bdf9: ecc: Add new function _gcry_mpi_ec_internal_new.
rC10b8cc280a53: ecc: Simplify ecc_encrypt_raw and ecc_decrypt_raw.
rC61a051828253: ecc: More fixes for cofactor with PUBKEY_FLAG_PARAM.
rCa258ae728de6: ecc: Simply use unsigned int for cofactor, not MPI.
rC579d5d6017d6: ecc: Simplify compute_keygrip.
rC95cc9b8f4483: ecc: Clean up key generation code.
o rCff0f1782560e: ecc: Handle ephemeral key as opaque octets.
rC80cf289905ac: ecc: Consolidate encoding a point for Montgomery curve.
rCba0b31f26366: ecc: More clean-up for Ed25519 and Curve25519.
rCd66a4856eb0c: ecc: Fix hard-coded value for 25519 to allow other modern curves.

Last week:

• For T4954: SOS representation and improvements in GnuPG, I realized that: ideally speaking, T4956: agent: Disrepancy of handling MPI for the interpretation of signed and unsigned and T4964: ecc: Disrepancy of handling MPI for the interpretation of signed and unsigned should be all fixed. But it's too much, very confusing, and possibly will introduce regressions (for SSH and GpgSM for signed data).
• The capacity of my brain is too small to find/identify/fix all possible problems for this.
• So, I'm focusing possible minimal change(s) for real use case of X448/Ed448.
• Tried to flash BC card for 3.4, and failed because of the card is too old. Asked Achim for sending new one.
• Side effect: confirmed that TTXS reader works well on Windows.
• Backport T4934 to 2.2
• Created: T4957: OpenPGP card protocol 3.4 with Yubikey

This week:

• continue on ECDH with X448, minimal change for SOS
• Data object FA support in scdaemon, and possible change of gpg-card/gpg--card-edit to show supported key attributes.

Change of gpg-agent for ECC-SOS

I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).