-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/build: add a Windows ARM builder #47019
Comments
Change https://golang.org/cl/344990 mentions this issue: |
This adds a windows-arm builder using host-windows-arm64-mini hosts. The new BuildConfig has a KnownIssue until we can verify that the builders are building correctly. For golang/go#47019 Change-Id: I0505d4dc367dbb687290facbddc718eb13567025 Reviewed-on: https://go-review.googlesource.com/c/build/+/344990 Trust: Alexander Rakoczy <alex@golang.org> Run-TryBot: Alexander Rakoczy <alex@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
Change https://golang.org/cl/345130 mentions this issue: |
The build is failing with 0xc000007b, which is an architecture mismatch. Instead, just set GOARM=7, which is aligned with the windows-arm-zx2c4 builder we are replacing. For golang/go#47019 Change-Id: I1f2aa18f6cdeb0dca4b234a164b915f2148f3936 Reviewed-on: https://go-review.googlesource.com/c/build/+/345130 Trust: Alexander Rakoczy <alex@golang.org> Run-TryBot: Alexander Rakoczy <alex@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
We're running into a 0xc000007b failure when attempting to run arm32 binaries in our arm64 windows installation. It could be either the version of windows we have installed, or a strange interaction with QEMU and HVM.
|
Change https://golang.org/cl/345330 mentions this issue: |
Binaries are failing to run with an 0xc000007b error. The cause is unknown. See the issue for details. For golang/go#47019 Change-Id: Ie0145a8cbe97745b632e420466fe13f6ff35fe17 Reviewed-on: https://go-review.googlesource.com/c/build/+/345330 Trust: Alexander Rakoczy <alex@golang.org> Run-TryBot: Alexander Rakoczy <alex@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
Do we have any actual ARM hardware that we could copy the image to in order to determine whether the problem is with the WIndows version or the emulated host? |
The latest insider build has arm32 issues, fyi, so be sure to run ordinary stable. Things seem fine on real hardware. |
Unfortunately, I couldn't get the stable version to run on the VM instances we're using. As I mentioned on #49266, I'll try updating the builders in my free time this weekend. I also couldn't reproduce on real hardware, but this seems related to the specific environment we're running on. Do you know if Windows ARM32 will continue to be supported? |
The idea is to run the ARM64 build of Windows and test ARM32 inside of it. Microsoft still supports ARM32 for IoT. If you think there's a good argument for sunsetting ARM32 in Go, though, then I guess that'd be a proposal to make, and then we could get some definition on it that way. |
We will be giving this another shot, as we're working on upgrading our windows builders this week. The holiday will slow things down a bit, but we're actually working on it. As a bonus, @heschi is doing it, which means updates won't be blocked solely on my availability. |
In case it helps,
You'll need to download llvm and such for cgo, but the above should hopefully get you past the, "it doesn't work at all!" phase, as the above does in fact work, and you can see ARM32 processes in the details view of task manager. |
@dmitshur Can we make this issue a goal for before 1.18 beta1? That way we're certain to have the beta1 period to fix bugs that might have slipped in since we went builderless a long while back, and therefore don't regress for 1.18.0. |
I'm actively working in this area, but it's a very complicated situation and I'm not confident it'll be done before beta. |
Anything I can do to help? What sorts of complications are you facing? |
The goal is to do this as part of #48946, but that's proving difficult. If you were going to work some sort of miracle, getting Windows 11 working on an AWS ARM machine would be my preference. |
You might have luck running it under QEMU inside of Linux, on an AWS ARM instance. And then capping the number of CPUs to 4 or 8 or something smallish. |
Yeah, we've had some minimal success with that, but with anything more than 4 cores it greenscreens. Even with 4 I think we've seen some instability. See https://cs.opensource.google/go/x/build/+/master:env/windows-arm64/aws/. I just finished verifying that the situation isn't any better with a recent Windows 11 and qemu. |
Huh, I wonder if that instability still holds on the Windows 11 stable channel images. |
I was trying with 22504; given that we've seen the same failures with a 6-month build and a fresh one, I don't think there's much hope for stable to be better :( |
Change https://golang.org/cl/377696 mentions this issue: |
Add a new host type, host-windows11-arm64-mini. It should support both ARM64 and ARM builds but for starters let's focus on ARM64. For golang/go#48946, golang/go#47019. Change-Id: I7ff07a97661fb6621237b9801ff0d0e338c6d4f4 Reviewed-on: https://go-review.googlesource.com/c/build/+/377696 Trust: Heschi Kreinick <heschi@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com> Reviewed-by: Alex Rakoczy <alex@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
@zx2c4 I finally, finally got to work on this and immediately faceplanted. Running anything with We're running the latest version of Windows 11, not IOT. I can't find a clear answer to whether that's supposed to support ARM32 binaries. Do you know what's going on here? |
Change https://go.dev/cl/391136 mentions this issue: |
Update the expected number of reverse buildlets to describe the current state more accurately. Update the windows-arm64 alias to point to windows-arm64-11, since it's more available and used for most recent releases. For golang/go#51546. Updates golang/go#47019. Change-Id: I5ae1a764efd21da4155ab002f20ad974b098b023 Reviewed-on: https://go-review.googlesource.com/c/build/+/391136 Reviewed-by: Carlos Amedee <carlos@golang.org> Trust: Dmitri Shuralyov <dmitshur@golang.org>
@zx2c4 any ideas? |
Change https://go.dev/cl/460295 mentions this issue: |
We no longer use this hosting provider. Removes builders depending on this host type, including Windows ARM builders. Fixes golang/go#57562 Updates golang/go#47019 Change-Id: I1b2d3dfb0540cdf1ebc1ce2cfabbcd7d56c30145 Reviewed-on: https://go-review.googlesource.com/c/build/+/460295 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Jenny Rakoczy <jenny@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
This issue was tracking adding this builder to the coordinator, but that's replaced with LUCI now. Closing this in favor of #67308. |
Our current builder (generously contributed by @zx2c4) is ready to be turned down. We need additional hardware to keep supporting this platform, and can re-use the infrastructure from #42604.
The text was updated successfully, but these errors were encountered: