Failing builds on Apple M1 due to CPU arch and GNU Coreutils

(1.1) By jakubgs on 2022-01-10 09:57:45 edited from 1.0 [link] [source]

I've discovered an issue with GNU Coreutils which manifests by returning a different processor architecture than the default MacOS uname utility does:

 > uname -m
arm64
 > uname -p 
arm
 > /opt/homebrew//Cellar/coreutils/9.0/bin/guname -m
arm64
 > /opt/homebrew//Cellar/coreutils/9.0/bin/guname -p
arm64

Because of this it's impossible to run ./configure on the new Apple Silicon M1 processor in an arm64 shell, because it fails:

[nix-shell:~/repos/sqlite]$ ./configure
checking build system type... Invalid configuration `arm64-apple-darwin20.6.0': machine `arm64-apple' not recognized
configure: error: /nix/store/ppzr8yab3s3883skd0da5i4ylzpksk9l-bash-5.1-p8/bin/bash ./config.sub arm64-apple-darwin20.6.0 failed

Specifically it fails because the config.guess and config.sub scripts is quite old, and fail to take M1 into account:

[nix-shell:~/repos/sqlite]$ bash ./config.sub $(bash ./config.guess)
Invalid configuration `arm64-apple-darwin20.6.0': machine `arm64-apple' not recognized

Now, if I update the most recent config.guess and config.sub it works fine:

[nix-shell:~/repos/sqlite]$ wget -O config.sub https://git.savannah.gnu.org/cgit/config.git/plain/config.sub
[nix-shell:~/repos/sqlite]$ wget -O config.guess https://git.savannah.gnu.org/cgit/config.git/plain/config.guess
[nix-shell:~/repos/sqlite]$ bash ./config.sub $(bash ./config.guess)
aarch64-apple-darwin20.6.0

These files in SQLite are quite old, specifically from 2019-05-28, so almost 3 years old. Updating it would resolve SQLite build issues one Apple Silicon M1 CPUs.

(2) By Warren Young (wyoung) on 2021-12-06 11:53:10 in reply to 1.0 [link] [source]

Yes, those files do need to be updated from time to time…

…but why are you using GNU/Homebrew tools on macOS in preference to the platform tools? It doesn't fail when you use Clang and /usr/bin stuff, so why go out of your way to invite trouble here?

(3) By jakubgs on 2021-12-06 12:25:37 in reply to 2 [link] [source]

I'm not, that was just an example. I'm actually using GNU Coreutils in Nix Shell.

https://nixos.org/

(4) By jakubgs on 2022-01-03 11:49:11 in reply to 1.0 [link] [source]

Any suggestions as to how I can deal with this?

(5) By Simon Slavin (slavin) on 2022-01-04 12:18:30 in reply to 4 [source]

It seems your problem is with homebrew, not SQLite. The SQLite team's recommended way to build SQLite is here:

https://www.sqlite.org/howtocompile.html

You can build SQLite projects with homebrew if you like, but if you have problems you're going to need someone who understands homebrew.

(6) By Wout Mertens (wmertens) on 2022-01-06 11:32:02 in reply to 5 [link] [source]

No, the problem seems to be that the config scripts that ship with SQLite are too old and need to be updated. Homebrew and Nix are not the issue here.

(10) By jakubgs on 2022-01-10 10:06:43 in reply to 6 [link] [source]

Correct. Homebrew does use GNU Coreutils, but it intentionally installs utilities like uname with a g prefix to avoid these issues caused by GNU Coreutils verison of uname:

 % which uname
/usr/bin/uname

 % which guname
/opt/homebrew/bin/guname

 % uname -p
arm

 % guname -p
arm64

 % ls /opt/homebrew/Cellar/coreutils/9.0/bin/uname
ls: /opt/homebrew/Cellar/coreutils/9.0/bin/uname: No such file or directory

 % ls /opt/homebrew/Cellar/coreutils/9.0/bin/guname
/opt/homebrew/Cellar/coreutils/9.0/bin/guname

(7) By Richard Hipp (drh) on 2022-01-06 11:51:05 in reply to 1.0 [link] [source]

I'm sorry you are having trouble. Unfortunately, I am unable to reproduce the problem on an Apple M1 processor running macOS Monterey 12.1 here. The ./configure script works. Running "./configure && make" works.

In the meantime, it seems like you have identified easy work-around.

(8) By Warren Young (wyoung) on 2022-01-06 12:21:19 in reply to 7 [link] [source]

The key difference seems to be whatever this NixOS environment does to the stock platform.

(9) By jakubgs on 2022-01-10 09:01:17 in reply to 8 [link] [source]

This is kinda correct. It's actually an issue with Coreutils. I have reported this bug to Coreutils Bug Report mailing list:

https://lists.gnu.org/archive/html/bug-coreutils/2021-12/msg00008.html

And Paul Eggert has applied a patch that I have confirmed as working: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e3d1ff04370b3e090e4cfeb8f6cc4a63590a516f

Unfortunately it will be a while before this fix is included in a release, since Coreutils releases something like every half year or so. And when it will be included in a Nix release is anybody's guess as well. One possible solution is building Coreutils from master branch, but that certainly isn't the safest way to do things. I have tested just applying the patch, but it depends on previous changes.

One really should update config.sub and config.guess from time to time though.