Proposal Details
The windows/arm port, which runs on a Windows with 32-bit ARM architecture, has been broken and unable to initialize the Go runtime since Go 1.18 (see #68552 and #70705). Even more, we haven't got a builder for ages.
From the Windows side, 32-bit ARM is no longer supported on Windows 11, as per these docs: https://learn.microsoft.com/en-us/windows/arm/arm32-to-arm64.
Windows devices running on an Arm processor (for example, Snapdragon processors from Qualcomm) will no longer support AArch32 (Arm32).
As a maintainer of the Go Windows port, having to keep up with the windows/arm port when changing the Go standard library (mainly the runtime package) is tedious and time consuming. Even if it doesn't really work, CI test that at least it can be cross-compiled, so I can't just pretend it doesn't exist.
Having said all these arguments, I propose to remove the windows/arm port support from the Go toolchain, tentatively targeting Go 1.25.
@golang/windows @golang/release
Proposal Details
The
windows/armport, which runs on a Windows with 32-bit ARM architecture, has been broken and unable to initialize the Go runtime since Go 1.18 (see #68552 and #70705). Even more, we haven't got a builder for ages.From the Windows side, 32-bit ARM is no longer supported on Windows 11, as per these docs: https://learn.microsoft.com/en-us/windows/arm/arm32-to-arm64.
As a maintainer of the Go Windows port, having to keep up with the
windows/armport when changing the Go standard library (mainly the runtime package) is tedious and time consuming. Even if it doesn't really work, CI test that at least it can be cross-compiled, so I can't just pretend it doesn't exist.Having said all these arguments, I propose to remove the
windows/armport support from the Go toolchain, tentatively targeting Go 1.25.@golang/windows @golang/release