Tiger's /usr/include/AvailabilityMacros.h seems to provide what rndlinux.c was looking for: libgcrypt 1.9.2 just built!

Alright! Here is the error report from GCC:

In T5250#143872, @kaie wrote:

It seems gpgme-json is intended to execute in the Web JavaScript sandbox of a browser.

I said "we're offering the optional use of GPGME

At the time I started to add an optional binding from Thunderbird to GPGME, I wasn't aware of gpgme-json.

In T5250#141705, @werner wrote:

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.

Fixed in libgcrypt 1.9.2. Thanks!

Backward compatibility fixed using the MacPorts legacysupport PortGroup:
https://github.com/macports/macports-ports/commit/74b50424649a7c657521140fcd7f92ba79a3cec5

This approach is too simplistic. See Ryan Schmidt's and Joshua Root's comments in https://trac.macports.org/ticket/62278

A beta release is available as https://gnupg.org/ftp/gcrypt/alpha/libgcrypt/libgcrypt-1.9.2-beta16.tar.bz2 (https://gnupg.org/ftp/gcrypt/alpha/libgcrypt/libgcrypt-1.9.2-beta16.tar.bz2.sig).

POSIX says so (use printf instead).
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

iirc the advise from the GNU coding standards is to use printf(1) instead of trying to figure out how echo(1) works.

Thank you. I'll fix. Perhaps, I'll ignore old UNIXen like AIX 6.1, which has no way to echo with no newlines.

Looks like this has been addressed in af23ab5c5482d625ff52e60606cf044e2b0106c8. A quick test building the current version in master with --disable-asm worked for me.

So, the change against libgcrypt 1.9.1 will be:

I got hit of search by "$ld$weak$os10.11$_getentropy".
So, I guess that it's 10.11 which has _getentropy as weak symbol, and 10.12 or later has implementation.

There is some (partly) good news: The function getentropy() is available in the packet manager MacPorts. It has a legacy support:

Unfortunately, building without "--disable-asm" does not work if building a universal package under MacPorts (e.g. 32bit and 64bit x86 or 64bit x86 and arm64).

In T5268#142714, @gniibe wrote:

To do that, I'd like to know, when the symbol getentropy was added.

no, that doesn't change anything.

In T5268#142612, @ballapete wrote:

Wouldn't it be better to move these failures as a single one into the configure script that it definitely can tell "This Mac has getentropy()"?

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 ...

Compiling now works, but I get the following linker errors:

@jukivili Thanks for the reply! We've reverted that commit downstream in Gentoo as a temporary workaround, as due to some complications, our release systems needed to build without asm (for now) to ensure portability. Rest assured, this is not the default, and is discouraged for regular users.

Building without "--disable-asm" works without any issues.

Thanks for your report.

FYI, this is not just an MacOS issue. We see that also on Gentoo Linux:

Wouldn't it be better to move these failures as a single one into the configure script that it definitely can tell "This Mac has getentropy()"?

I applied the two patches on Mac OS X 10.5.8, Leopard, to random/rndlinux.c, resulting in this unified diff:

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 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

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

Does attached patch help?

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

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:

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.

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.

OK, then we'll have to live with --disable-asm until the next major version is released, or switch to gcc.

We should not do this.

AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.

In T5157#139622, @gniibe wrote:

ARM64 has been only tested on platforms which support ELF.

While it doesn't looks good (using AMD64 even if it's ARM64), I think this patch should be applied:

diff --git a/cipher/asm-common-aarch64.h b/cipher/asm-common-aarch64.h
...

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

I created D513: Support macOS build with SIP by using posix_spawn in tests/random, which is more conservative; It only affects build under macOS.

In T5159#139739, @werner wrote:

Put

extern char **environ;

after the the include directives.

Put

extern char **environ;

after the the include directives.

After applying @gniibe 's patch:

The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.

BTW, I'm not sure if the claim in T5009#136688 is correct.

See also: https://dev.gnupg.org/T5009#136688

See my comment in: https://dev.gnupg.org/T5024#139701

After disabling SIP, now all checks pass without having the library symlinked to /usr/local/lib. So it might be T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error after all.

After doing:

Another issue that comes in to mind is that current ARM/ARM64 HW feature detection most likely wont work on MacOS. Thus HW accelerated AES&SHA&GHASH implementation wont be used.

IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c

HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS is never defined on ARM64 as it depends on "$mpi_cpu_arch" == "x86". Instead I think new check for GCC assembly ELF directives would be needed in configure.ac, similar to HAVE_GCC_ASM_CFI_DIRECTIVES check. Following check should work, but I have not yet tested it:

ARM64 has been only tested on platforms which support ELF.

Yes, I did. Identical result.

Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

And the arm64 cross-compiler:

Sorry, I forgot to mention that Apple ships a gcc-wrapper for clang. It just accepts gcc command lines parameters and translates them to clang parameters.
Here is the output of gcc --version:

You say that you build using clang but the log shows that you invoke gcc.

Please ask your distribution . What I see here is a problem with the packaging of a dedicated build system. This is not the build system which comes with GnuPG. Feel free to reopen if you can show that this is a native gnupg build problem.

I am the worst. I totally forgot about this.

No more information, can't proceed, thus, closed.