Patch lets it build on xenial for me, thank you.

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

I committed the partial result docker container, so I can restart it for investigation. So:

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.

See T5267: Ed25519 backward compatible private key support for preceding ZERO(s) for the fix.

In the next few days I'll be able to boot into Leopard, Mac OS X 10.5.8, to test this. Right now it seems that I need to fix a few problems with updated software sources…

Thank you for your testing.

In T5268#142155, @gniibe wrote:

To support old macOS (< 10.12), I think that code should be something like this:

After libgcrypt 1.9.0 first built on Tiger and 'make check' succeeded I ran 'make clean' and applied the changes to random/rndlinux.c. A simple make succeeded without problem. 'make check' then ran into problems, spitting out many times messages messages like these:

Push the change.
For older versions of MacOS X, I'll handle it later.

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/posix_spawn.2.html dated August 9, 2007.
So, I guess that posix_spawn became available in MacOS X Leopard (10.5).

I wrote:

I don't know when the symbol of getentropy was available on macOS.

@ballapete Thank you for testing.

Also support older MacOS X, which has no posix_spawn.

In T5264#142204, @jukivili wrote:

I also needed this patch:

0001-global-fix-compile-error-at-pragma-GCC-diagnostic.patch2 KBDownload

I am going to check whether I need it on Tiger!

In T5264#142204, @jukivili wrote:

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

I see now my mistake: I also have to re-write line #132 which I did not see yet!

With your other patch I still get:

libtool: compile:  /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I../mpi -I../mpi -I/opt/local/include -I/opt/local/include -pipe -Os -std=gnu89 -arch ppc -fno-delete-null-pointer-checks -Wall -MT cipher.lo -MD -MP -MF .deps/cipher.Tpo -c cipher.c  -fno-common -DPIC -o .libs/cipher.o
In file included from cipher.c:31:
./cipher-internal.h:145: error: redefinition of typedef 'cipher_bulk_ops_t'
../src/cipher-proto.h:132: error: previous declaration of 'cipher_bulk_ops_t' was here

In T5264#142203, @jukivili wrote:

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

The "Portfile" that conducts the build process has the patch contained, I sent you the list of files being patched, and here is the end of my translated patch set:

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.

In T5264#142094, @jukivili wrote:

Here's patch to try out:

0001-cipher-proto-remove-forward-typedef-of-cipher_bulk_o.patch6 KBDownload

In T5268#142155, @gniibe wrote:

To support old macOS (< 10.12), I think that code should be something like this:

diff --git a/random/rndlinux.c b/random/rndlinux.c
index 04e2a464..f378a549 100644

In T5264#142064, @jukivili wrote:

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

Performing only this change leads consistently to the well-known error of:

In T5264#142059, @werner wrote:

Do not use -fno-common

The translated bulk patch fails. Compilation still runs into this error:

In T5264#142094, @jukivili wrote:

Here's patch to try out:

0001-cipher-proto-remove-forward-typedef-of-cipher_bulk_o.patch6 KBDownload

Alright!

@ballapete when you have time, could you also test https://dev.gnupg.org/T5268#142155 on Tiger?

To support old macOS (< 10.12), I think that code should be something like this:

• For Ed25519 private key segfault: see T5267
• For macOS getentropy: see T5268
• For invm failure: see T5269

Right now I am compiling with my old PowerBook in Tiger. In case a compilation fails I'll try this patch – on Tiger (Mac OS X 10.4.11)! It's a bit more primitive than Leopard.

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.