I have tool version managers in the Ruby and react-native worlds that (underneath the layers of abstraction) end up building software like Ruby from source using a fairly mundane:
./configure ./make ./make install
... with various options passed into those commands from the abstractions above.
On my M1 MacBook Pro I find I have to carefully pass in command line options to get the build to understand what architecture I am running. For instance:
export CONFIGURE_OPTS="--build aarch64-apple-darwin20"; asdf install ruby 2.6.6
...prevents configure from breaking during
asdf install with an error like,
machine not recognised.
Digging down I can see a
config.sub file in the build directory that was created in 2007. It doesn't know anything about the arm64 architecture.
I am fairly certain that the problem is here because
./configure succeeds if I substitute a 2021 version config.sub from another project and try again.
I am very surprised to find that colleagues who are installing the same software on M1 machines with the exact same
asdf install... process do not have any such hassles.
This is not
asdf-specific, I have the same problem with dependencies installed by CocoaPods, which is also underneath it all using
make, and similarly my colleagues do not have any problems.
Something on other people's machines (or mine) is overriding the results of config.sub, or must be giving them a different copy of config.sub. I am mystified.
Update: one significant difference between the "working" machines and mine seems to be the output of uname:
Darwin 192.168.1.102 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101 arm64 arm64 MacBookPro17,1 Darwin
Darwin Joes-MacBook-Pro.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64
uname -p reports
arm on others' machines and
arm64 on mine.