#2659: ExternalLibrary auto-detection fails on M1 macs using homebrew

Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component:

With @{6350afe6fe5ff37523587456} I just dug down a bit into compilation failures using HomeBrew on macOS M1.

There were three errors reported at CST stage by ExternalLibraries;

``` CST error 1: -> Configuration script for thorn LIBJPEG returned exit code 77 (no error message) CST error 2: -> Configuration script for thorn OPENSSL returned exit code 2 (no error message) CST error 3: -> Configuration script for thorn ZLIB returned exit code 1 (no error message) ```

which turn out to be compilation failures, at least in LIBJPEG’s case. Now libjpeg should not even be attempted to be compiled since the tutorial instructions (which were followed) contain `brew install jpeg` and indeed `jpeg` was installed.

It turns out that HomeBrew moved from `/usr/local` to `/opt/homebrew` so that the rather limited set of locations checked by many ExternalLibraries no longer match. `pkg-config` is not help here either it seems.

Part of this is already broken on x86 macs where HomeBrew does not install `OpenSSL` and `zlib` into `/usr/local` but only into its own `Cellar` hierarchy so that the installed copies are being ignored already on x86 macs (verified on my own x86 macOS VM).

With this we can no longer claim macOS support using homebrew. If similar issues occur using macports then we can no longer claim any macOS support.

Fixes would involve finding out why pkg-config fails and also why compilation attempts fail. Looking at the log files for libjpeg it tried using `gcc` (ie Apple’s clang-in-disguise) instead of the correct `gcc-12` from homebrew. This, unsurprisingly failed. Similarly for OpenSSL (fails due to lack of support of `-fopenmp`) and similar for zlib.

‌

This will need a M1 owner to step forward as a volunteer to help fix this.

-- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2659/externallibrary-au...