I have now tried to build libgcrypt 1.9.0 for arm64 using clang. I get the following error:

It seems that this issue has already been reported with a better fix: https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005060.html
Feel free to close this issue.

Should we add this to the hints in the README? After all this does not seem to be the standard system compiler or it has not been properly setup as replacement.

Problem was that my build system was selecting "ar" and "ranlib", where as your build system selects "llvm-ar" and "llvm-ranlib".

In T5255#141976, @jukivili wrote:

Unfortunately these are not enough to enable building with clang LTO. Build now fails when linking test executables (libgcrypt.so gets build however):

Any ideas what might be causing this?

Configure output has still has some differences LTO vs non-LTO:

--- non-lto.log 2021-01-21 22:25:14.966099577 +0200
+++ lto.log     2021-01-21 22:25:23.174086100 +0200
@@ -63,7 +63,7 @@
 checking for archiver @FILE support... @
 checking for strip... strip
 checking for ranlib... ranlib
-checking command to parse /usr/bin/nm -B output from clang object... ok
+checking command to parse /usr/bin/nm -B output from clang object... failed
 checking for sysroot... no
 checking for mt... mt
 checking if mt is a manifest tool... no
@@ -75,7 +75,7 @@
 checking if clang static flag -static works... yes
 checking if clang supports -c -o file.o... yes
 checking if clang supports -c -o file.o... (cached) yes
-checking whether the clang linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
+checking whether the clang linker (/usr/bin/ld) supports shared libraries... yes
 checking whether -lc should be explicitly linked in... no
 checking dynamic linker characteristics... GNU/Linux ld.so
 checking how to hardcode library paths into programs... immediate
@@ -168,8 +168,8 @@
 checking whether 'asm' assembler keyword is supported... yes
 checking whether '__asm__' assembler keyword is supported... yes
 checking whether inline assembly memory barrier is supported... yes
-checking whether GCC assembler is compatible for ARM assembly implementations... no
-checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... no
+checking whether GCC assembler is compatible for ARM assembly implementations... yes
+checking whether GCC assembler is compatible for ARMv8/Aarch64 assembly implementations... yes
 checking whether GCC assembler supports for CFI directives... yes
 checking whether GCC assembler supports for ELF directives... yes
 checking for _ prefix in compiled symbols... no
@@ -240,7 +240,7 @@
 checking if gcc supports -Wno-missing-field-initializers... yes
 checking if gcc supports -Wpointer-arith... yes
 checking whether non excutable stack support is requested... yes
-checking whether assembler supports --noexecstack option... yes
+checking whether assembler supports --noexecstack option... no
 checking that generated files are newer than configure... done
 configure: creating ./config.status
 config.status: creating Makefile

Clang support Intel syntax after all, but not assembler macros that were used. Here's two patches that fix the configure.ac issue and removes use of assembly macros in Intel syntax assembly files:

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.

Sure. Thanks for testing. The problem with new versions is that ppl don't like to test release candidates and thus we need do real releases and wait for the outfall. ;-)

Breakage appears to happen in configure.ac. When building with clang without LTO following check gives "no":

Fixed by jukvilli’s patch.
__outer

That works, thanks. So does that become part of the next release?
__outer

Both are affected. I updated to reflect that I tested the newer version

Thanks for the reports. IIRC, we had similar reports in the past either here or on a ML.

FWIW, after the release I had some time and after some trouble with my Pi4B I ran into the same problem.

So is this about 1.8.7 or 1.9.0 (as shown in the Version field)?

In fact, Thunderbird does not use gpgme-json, but loads the gpgme shared library at runtime. The interesting thing is that Thunderbird works fine if gpgOSX is used.

Yes, clang + LTO is broken. Maybe there is issue in clang bug tracker for this already?

Maybe this patch helps:

Similar to T5252, likely requiring the concept of some kind of "fixed reference date".

Confirmed working after applying your patch!

The fix will be part of the upcoming pinentry-1.1.1.

Thanks for you report.

@gniibe I assume this issue has been fixed by the same fix as for T4585 and can be closed as well. Feel free to re-open if I am wrong.

Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.

Thanks for the reply. Not sure about GPGME/gpgme-json. Anyway, it still ends up in gpgme code, isn't it?
I used to modify gpgme sources to receive more information about the issue.
Looks like the next step would be to modify gpg-conf and see what's going on there, or leave it to the Thunderbird developers.

Sure that TB uses GPGME - they claimed they won't use it due to license incompatibility (LGPL). I assumed they use gpgme-json via naticve messaging. Regarding the error - I have no idea.

Thanks for the feedback

Ok, I found the message and tried some opening and clicking around w/o any crashes. But back then I also couldn't reproduce it. Please close the issue. I'll ask for reopening if I ever come across it once more. Thanks for your good work!

For a bug which requires more tests (like this one with GnuPG and pinentry), I had a practice to put "Testing" tag.

Any news about this bug? It has been in “Testing” for quite a while now. For what it’s worth, handling of ^C seems to work here as I would expect, so I am inclined to close here and let pinentry-1.1.1 go out. @gniibe, as you did the fix, do you have any comment?

I set it to Normal priority. It would be good to find out what exactly is the problem with this key so that we can fix this in kleopatra and handle it.

The about dialog where it tells unknown windows version means it's Gpg4win-3.1.13 (the only version affected by T5056 )

It's version 2

Please let us know your gpg4win version.

I am getting the initial exception again:

That would mean I could remember the exact problem. Can you extract the mail name from my logs? I should still have it...

Note: The commit in master (1.9) is rCe0898d0628789414
and in 1.8 it is rC03e6d6597198ee

The commit which fixes this is rC761a1a0d30

This works with the message class changing. We still need to do it for OpenPGP, too.

The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.

Yes, bug is also in 1.8 branch.

I'm also getting this same error with GPG4Win 3.1.14.

Do we need to backport to 1.8?

Thanks. I added the OIDs and the missing curves. To go into 1.9

Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html

This works now with 0c1bd9076958e584820fadf997ca7d8a248b6888 but needs more testing before this can be relased. It will probably be part of a Gpg4win-4 beta.

I'd suggest to first try the current version to see whether the bug has been solved.

Please try gpg4win 3.1.14 and check whether your problem has gone.