Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uname -m is unreliable in detecting architecture #5853

Closed
blinkybool opened this issue Feb 22, 2024 · 2 comments
Closed

uname -m is unreliable in detecting architecture #5853

blinkybool opened this issue Feb 22, 2024 · 2 comments

Comments

@blinkybool
Copy link

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?

@jbhoot
Copy link

jbhoot commented Feb 23, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants