The download website makes it easy for all macOS users, even the ones running on Apple Silicon, to download the amd64 package. This is #52487.
As described in https://github.com/golang/go/issues/52487#issuecomment-1466854907, this mostly works, and users can go on quite a while not realizing that they're running the Go toolchain under emulation (and producing amd64 binaries which are also running under emulation). The problems that eventually arise can be very subtle.
Besides fixing the website download links, we should consider making the amd64 installer refuse to run on arm64 chips or at least warn the user that they are not installing the correct package for their architecture.
Comment From: cespare
This is tangentially related to #58235.
Also cc @golang/release and @dmitshur.
Comment From: hyangah
Another idea is whether the installer carries only a bootstrap part (either universal, or a binary running on rosetta, or a bash script) and during install, it downloads the right versions. For extended forward compatibility support (https://github.com/golang/go/issues/57001) I think there will be compact versions of core toolings and standard libraries. I wonder if they can be utilized.
Comment From: stapelberg
I also just ran into this when trying to update the Go installation on my Mac in a hurry.
I looked around whether we could make the installer prompt users, but it seems like that’s not (easily) possible:
- https://stackoverflow.com/questions/23086649/how-do-you-ask-the-user-questions-in-an-os-x-installer-built-with-pkgbuild-produ
- https://apple.stackexchange.com/questions/359182/how-to-create-a-pkg-installer-with-a-custom-action
Another idea is whether the installer carries only a bootstrap part (either universal, or a binary running on rosetta, or a bash script) and during install, it downloads the right versions. For extended forward compatibility support (#57001) I think there will be compact versions of core toolings and standard libraries. I wonder if they can be utilized.
It’s a good thought, but that would mean the installer no longer contains the toolchain and is only a shim for downloading a toolchain. It’s certainly a possibility, but a change to the current model (turning an offline-capable installer into a network-required installer).
Another thought: Maybe, instead of trying to prevent the issue, we can at least detect the issue more clearly. Perhaps, in go version, we could print a message when running under rosetta translation? It seems like Go programs can detect this state: https://github.com/golang/go/issues/44733
Comment From: gopherbot
Change https://go.dev/cl/682015 mentions this issue: internal/installer/darwinpkg: detect amd64 installer on arm64 host