It seems that Apple Silicon support has been added in https://github.com/python/cpython/pull/22855, but when I try to build locally I see this error:

```
% ./configure
checking for git... found
checking build system type... Invalid configuration `arm64-apple-darwin20.3.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin20.3.0 failed
```

I went through the `autoreconf` instructions to see if the checked in configure script was outdated, but it doesn't seem to have fixed the issue.

I was able to fix this locally by updating the config.sub and config.guess files (only the former was required but I noticed in previous updates that they were updated in lockstep). I'm a bit wary about that change because it doesn't seem like they are updated frequently (they haven't been in over 3 years), but I will submit it for discussion.

The files are auto-generated by autoconf. The common Linux platforms do not have autoconf 2.71 yet. A large amount of core developers use Debian, Fedora, or Ubuntu. The latest releases of these distros only have autoconf 2.69.

Until we can update, you have to recreate the configure script locally.

It looks like we might be able to update the files after all. It's hard to say, though. The older tickets and commits for config.guess don't contain much context or explanation.

Thanks for taking a look. My limited understanding is also that these should be able to be updated separately from autoconf, and I feel slightly more confident knowing that in the past folks treated this update as trivial. It seems like the changes should be entirely additive, as in they support new triples but otherwise are API compatible.

I'm unable to reproduce the failure you see using the current top of the master branch (or the 3.9 branch) when running ./configure on an M1 Mac with macOS 11.2.3 and Xcode 12.4. The results I see are:

checking build system type... arm-apple-darwin20.3.0
checking host system type... arm-apple-darwin20.3.0

How are you producing the source that you are building from?

Thanks for checking, I was able to debug further and it turns out the actual issue is if you use `uname` from `coreutils`, you get different results:

```
% /opt/homebrew/opt/coreutils/libexec/gnubin/uname -p
arm64
% /usr/bin/uname -p
arm
```

I have this in my $PATH (not specifically for uname but for other coreutils binaries) which is what lead to this. This update fixes this because the newer config.sub version contains a case for `arm64` that didn't exist before https://github.com/python/cpython/pull/25450/files#diff-9c966208fd0a0c8e24a1526da6904887c378283b9b645b9740c19339884174d9R1107

So this isn't as big of an issue as I thought, but I still think it makes sense to update these files.

Thanks for the additional info and the PR. Yes, it probably does make sense to update them. But it also makes sense to avoid getting into problems building (Python and likely some other projects) with replacements for Apple-supplied utilities :)  I note that MacPorts installs coreutils with a "g" prefix (e.g. "guname") for just this reason.

Yep for sure, this is the first time I've hit a difference with uname specifically

In case it changes the calculus on how to proceed, HomeBrew does install coreutils with a "g" prefix -- a user needs to explicitly add the gnubin directory to their path in order for the unprefixed version to take precedence over the Apple-supplied one.

https://github.com/Homebrew/homebrew-core/blob/4d04d78d5c27bde0da4e21b0669156b57c2d0839/Formula/coreutils.rb#L88-L91
https://github.com/Homebrew/homebrew-core/issues/71782

I think given that this file seems to be updated occasionally anyways we should still land this. I agree with the sentiment that if this was a super specific fix just for this edge case maybe it wouldn't be worth it.

Someone nonchalantly updated these in https://github.com/python/cpython/commit/2fc857a5721a5b42bcb696c9cae1bbcc82a91b17 so this bug is now fixed

> Someone nonchalantly updated these in https://github.com/python/cpython/commit/2fc857a5721a5b42bcb696c9cae1bbcc82a91b17 so this bug is now fixed

That PR only goes into 3.11. While this ticket claims to have fixed the problem for 3.10 as well.

Should that PR be backported? Alternatively, https://github.com/python/cpython/pull/25450 should be merged, but into `3.10` instead of `master`.