Subject: bug#52330: Different processor architecture on Apple M1 CPU

From: Jakub Sokołowski <[email-masked]>
Date: Mon, 6 Dec 2021 15:53:10 +0100

I've identified an issue with GNU Coreutils uname utility. Specifically
with the value it returns for the processor type/architecture(-p). When
used on a MacOS with M1 arm64 processor the returned value is amr64, but
the default uname utility on MacOS returns arm.

This issue has caused build issues with SQLite and SQLCipher packages when
trying to build them on 4th generation Mac Mini inside of a Nix shell which
uses GNU Coreutils. It wails with:

[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

I've tried to get to the bottom of this issue when trying to get our iOS
builds to work on arm64:
https://github.com/status-im/status-react/issues/12799

And initially I thought this was specific to Nix, so I opened an issue for
it:
https://github.com/NixOS/nixpkgs/issues/147914

But as suggested there the issue appears to be in GNU Coreutils.
I also tried fixing the build in SQLCipher by updating their `config.sub`
and `config.guess` scripts, but the PR was rejected:
https://github.com/sqlcipher/sqlcipher/pull/414

I've also opened a thread on SQLite forum about this issue:
https://www.sqlite.org/forum/forumpost/f0875bea54

But not sure if they would want to update their `config.sub` and
`config.guess` either.

Is this something that can be fixed in GNU Coreutils?