uname -m is unreliable in detecting architecture

[blinkybool]

On an apple silicon mac, if the gnu coreutils are in the PATH, uname -m will always report x86_64, since the binary /usr/local/opt/coreutils/libexec/gnubin/uname is compiled for x86_64, so Rosetta is triggered to run it. Prefixing arch -arm64 does not change this, and I do not have "Open in Rosetta" checked on my terminal applications.

This caused a lot of confusion for me when failing to build the ocaml compiler in with opam, since it tries to compile for the wrong architecture. (opam config report gives x86_64 for the system architecture).

I don't know for what purpose in the past that I had installed the gnu coreutils, but it was probably something fairly commonly installed. This problem is also discussed here Homebrew/homebrew-core#71782

Can the opam internals and install script use something other than uname -m to detect architecture to avoid this? Perhaps use the arch command on mac os, or check that uname is a universal binary, or detect the gnu coreutils in which uname?

[jyssh]

GNU coreutils also contains arch. See the list here.

So if GNU coreutils overrides the native binaries in PATH, then arch command is probably also using the binary from coreutils.

Even if coreutils's arch provides the correct answer right now, given the different response from coreutils's uname -m and arch, arch should not be relied upon too.

If homebrew hasn't packaged arch in the coreutils, then there is still no telling that it won't in the future.

Basically, switching to arch may not be beneficial.

May be we should make sure to use the native uname binary, like /usr/bin/uname. One concern is hardcoding the full path, but if the native binary has moved from that location, or if a non-native binary exists in that /usr/bin/uname, then we could safely assume that the system already has bigger problems than not being able to install opam.

[kit-ty-kate]

While opam could create a custom C stub to use uname(2) (such as in #4274) to fix this specific errors with uname, this wouldn't be the only breakage in such an environment and we expect users to provide a consistent environment via PATH which is not the case when coreutils (or similar packages such as binutils) is part of the PATH on macOS.

I would highly discourage anyone from using coreutils on macOS by default and instead use brew unlink coreutils when you explicitly want the coreutils tools.