Also, and I should maybe have opened with it, the issues vcpkg has with your build system are currently tracked here, while my effort to build gpg-error natively (i.e. without relying on ShiftMediaProject fork) on all platforms is here.

In T5365#151844, @gniibe wrote:

Let me clarify the use case of gpg-error.m4.

gpg-error.m4 is for GnuPG and its friends, where we cannot assume availability of pkg-config. Its capability is limited, and we don't pursue 100% compatibility of pkg-config.

Let me clarify the use case of gpg-error.m4.

In T5365#144688, @gniibe wrote:

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

Please talk to the KDE folks who develop Craft. We do not support building anything with Craft. Check out gpg4win (https://dev.gnupg.org/source/gpg4win/) to see how we build our products on Windows.

I was wrong in my last comment. Escaping by another \ is needed.

A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).

@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).

Or, if we keep the code of newline (so that it will eventually support path with a space in future):

Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.

@gniibe OK, so... "worst case": I guess this worked? ;P

@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(

@gniibe Ah yeah, that was the commit I meant to reference when I said "--maybe caused by --", but then forgot to go back and fill in the commit hash ;P.

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.

In T5257#141913, @jukivili wrote:

You probably define CFLAGS=-m32 in your installation script for 32-bit build. I'd try with CFLAGS="-O2 -m32".

Thanks for report. I reproduced this by building i386 with optimizations disabled "-O0" (gcc 10). With normal optimization level such as "-O2", the issue does not appear.

I believe the problem was fixed in the master of pinentry with newer gpg-error-config and libassuan-config which support cross build better.

In order to work around this potential bug I do the following at the moment:

1. Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.

2. Restore: (a) Import the ASCII-armored *public* key together with its subkeys. (b) Import the ASCII-armored *secret* key together with its subkeys.

The actions [1.(b)] and [2.(a)] should not be necessary if there was not this
potential bug.

I further tried to find the action that causes the potential bug with an another
test key as follows:

1. Create a certify-only RSA4096 primary key.

2. Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}

3. Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --

export 0xEEE9979BE8C80E95

4. Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --

export 0xB6BF97893ACA0C17

5. Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95

6. Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt

7. Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}

8. Repeat action 1. to 7. by: (a) Adding a sign-only RSA4096 subkey. (b) Adding a encrypt-only RSA4096 subkey. (c) Change the expiry date of the encrypt-only RSA4096 subkey.

ERROR: *Changing the expiry date*, exporting, purging, importing the primary key
with its 2 subkeys makes the first sign-only RSA4096 subkey disappear from the
pubring.gpg file but not from the secring.gpg file.