Here's patch to try out:

BTW, we should better get back to the classic/GNU-coding-style pattern:

In "src/cipher-proto.h", try removing typedef and leaving just forward declaration of structure.

Do not use -fno-common

Does attached patch help?

I tried it - that doesn't help. Same error message.

Thanks for the report. As you noticed, issue had been reported already.

That might be helpful. But, on the other hand, if I had just googled the problem I was seeing I would have gotten answer quite fast.

Problem is in GET_DATA_POINTER macro. MacOS assembler expects data references in some different format than Linux. Could you try following edit and see if libgcrypt then compiles? In cipher/asm-common-aarch64.h, there is definition of GET_DATA_POINTER macro:

#ifdef _WIN32
#define GET_DATA_POINTER(reg, name) \
	adrp    reg, name ; \
	add     reg, reg, #:lo12:name ;
#else
#define GET_DATA_POINTER(reg, name) \
	adrp    reg, :got:name ; \
	ldr     reg, [reg, #:got_lo12:name] ;
#endif

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:

Merged to master.

Merged to master.

Merged to master.

Merged to master.

Merged to master.

Merged to master.

Merged to master.

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

• For build problems on Raspberry PI see T5251 for a patch
• If you run into "selftest" error see T5254 for a patch (which should be applied in any case)

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

Confirmed working after applying your patch!

Thanks for you report.

We plan this for 1.10 but it may also go into one of the next 1.9.x releases

Docs done.

I am not sure. MD5 is still important for some applications, say CRAM-MD5. IIRC, back in 2008 we dis-allowed RMD160 and added separate RMD160 code directly to gpg to fulfill FIPS requirements.

Okay for 1.9.

Note that even after rCce1cbe16992a: Disable non-allowed algorithms in FIPS mode, gcry_md_open won't return an error with disabled algo.

The changelog in https://src.fedoraproject.org/rpms/libgcrypt/c/402a3b5f2eed746bea996c5743c99bec9bbc3487?branch=master