Note that rndjent.c is already build with -O0 as can be seen in example above. That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

@werner Can you comment about bugfix release?

These functions are internal to library and, for example, on linux/windows builds are not externally available.

This patch should work if configure properly detects need for extra underscore on C symbols:

Thanks for the report.

Pushed to master with two commits:

• https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=440332532a1c107e2baeafda5464e0707f634be1
• https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=760ef8baee06db5ce4da55eb5648e605aa511d2d

I posted patch-set to mailing-list. Please check if AUTHORS/LICENSES updates are ok.
https://lists.gnupg.org/pipermail/gcrypt-devel/2021-March/005120.html

I've cleaned up the patch from D501 and tweaked the implementation a bit for performance. Here's patches attached:

Fixed typos and applied to master. Thanks.

Problem with clang and these files was resolved by replacement of assembler macros with C preprocessor macros.

The 'what != NULL' case is handled by the "Strip trailing LF" part at the end of function. These data strings always end with '\n', so null-termination gets done there.

Does it build if configure with parameter 'ac_cv_sys_symbol_underscore=yes'? <path-to-libgcrypt-source>/configure ac_cv_sys_symbol_underscore=yes --host=aarch64-apple-darwin ...

Thanks for your report.

Patch for this bug is available here, "attachment-0001.bin": https://lists.gnupg.org/pipermail/gcrypt-devel/2021-January/005079.html

I tested xenial with gcc-5.3 (xenial distro repo) and gcc-5.4 (xenial-updates distro repo) and libgcrypt 1.9.0 from git repo and from tarball. I did not get any errors.

I tested building on Ubuntu 8.04 (gcc-4.2) and got same error about cipher_bulk_ops_t. Applying patch fixed that problem.

Thanks for testing. However, I do not believe patch has been correctly applied.

Here's patch to try out:

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

Does attached patch help?

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

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

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.

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.