Nix Shell returns arm64 processor architecture on M1 Mac

[jakubgs]

Describe the bug

I've discovered that the results of uname -p are different in Nix shell compared to all other shells:

[nix-shell:~]$ uname -p
arm64
[nix-shell:~]$ uname -m
arm64

I do not know if this behavior is not causing other issues in other places.

Steps To Reproduce

1. Run Nix on 5th Gen Mac Mini with Apple Silicon M1 CPU
2. Open nix-shell of any kind
3. Check output of uname -p

Expected behavior

I'm not 100% sure if the correct behavior is to show arm when uname -p is called, but this is what other shells do:

Env	uname -p	uname -m
/bin/bash	arm	arm64
/bin/zsh	arm	arm64
/opt/homebrew/bin/zsh	arm	arm64
nix-shell	arm64	arm64

Additional context

Discovered while trying to resolve build issues with SQLCipher for our application in status-im/status-mobile#12799.
This is causing a build failure for SQLCipher because the configure script expects arm instead of arm64.
I have already opened an issue for that: sqlcipher/sqlcipher#413

Notify maintainers

Not sure who...

Metadata

 - system: `"aarch64-darwin"`
 - host os: `Darwin 20.6.0, macOS 11.6`
 - multi-user?: `no`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.16`
 - channels(jenkins): `"nixpkgs-21.11pre333180.98747f27ecf"`
 - nixpkgs: `/Users/jenkins/.nix-defexpr/channels/nixpkgs`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

[jakubgs]

According to this issue this is normal on M1 machines:

I can reproduce what you are seeing on our Macs on 11.2.3 and 11.3.1 - we get arm64 / arm / arm64 reliably back despite different shells and homebrew (or lack thereof) setups on each.

https://apple.stackexchange.com/questions/420452/running-uname-m-gives-x86-64-on-m1-mac-mini

[jakubgs]

Apparently current version of config.guess from GNU Config repo because it includes the following fix.

Thanks to that the architecture reported is aarch64-apple-darwin20.6.0 instead of arm64-apple-darwin20.6.0.

This might be able to fix my issue if such updated config.guess is used, but the return value from uname -p might still be an issue for other software and build setups.

[jakubgs]

My fix for SQLCipher was rejected. Seems to me like this needs to be fixed in the Nix shell itself and how it reports the processor architecture.

Based on contributions in #95903 I'm going to ping @domenkozar and @kloenk.

[autc04]

Apparently, this is a difference between GNU coreutils' uname and Apple's uname.

[jakubgs]

Oh yeah, @autc04 you're right, if I try the uname provided by Homebrew returns arm:

 > 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

So this might actually be an issue with coreutils from GNU. I'll take a look at their bugs list.

[jakubgs]

Thanks to help from Paul Eggert we now have a patch in GNU Coreutils that fixes this:

• https://lists.gnu.org/archive/html/bug-coreutils/2021-12/msg00008.html
• https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e3d1ff04370b3e090e4cfeb8f6cc4a63590a516f

Thanks @autc04 for suggesting this might be specific to coreutils. When this gets into a release is anybody's guess.