runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values #38485
Comments
|
If darwin/arm64 doesn't work for macos, I've thought about whether we should have GOOS=macos Interesting to note that way back when, we could have done |
|
I think the suggestion here is:
This will potentially break any existing mobile programs that test This suggests that for 1.15 we should
|
|
CC @hyangah |
|
I think (but not sure) gomobile sets ios tag, to distinguish iOS emulator on x86 vs. macOS. |
|
gomobile uses ios tag and also we use the ios tag in crypto/x509 package.
gomobile sets GOOS/GOARCH for crosscompile so it needs to use the right
value depending on the go version. I don't think that's too difficult.
In addition to gomobile, cc/ @eliasnaur <elias.naur@gmail.com> for gio,
@hajimehoshi for ebiten users
…On Fri, May 1, 2020 at 2:38 PM cherrymui ***@***.***> wrote:
I think (but not sure) gomobile sets ios tag, to distinguish iOS emulator
on x86 vs. macOS.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#38485 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGESL63JC4FILQFUNGUQH3RPMJJPANCNFSM4MJZNOPQ>
.
--
__
|
Also interesting is that Apple currently has macOS, iOS, iPadOS, tvOS, and watchOS. |
|
As far as I know about mobile application developing, there should be no problem to add |
|
Change https://golang.org/cl/239278 mentions this issue: |
|
I expect we will learn relevant official information from Apple's WWDC 20 Keynote later today, and be able to use that information to make any definitive 1.15-specific decision. However, given we are well into the code freeze for 1.15 with not much time left, and a change to build tags now would require getting a freeze exception (per bullet point 3 from the planning thread), I started investigating the plan for 1.15 @ianlancetaylor described in #38485 (comment) in advance to learn more and be able to move quickly today if needed. Based on what I've learned from the investigation (also see a draft DNS CL 239278), I suspect we will not need or want to make any code changes for 1.15, only add a note to the release notes. The rationale follows. The motivation behind doing "add Work to add a new port must be started before the code freeze, so by now we know for sure that Go 1.15 will not be able to support macOS on any new architectures beyond This suggests for 1.15 it's likely sufficient to update release notes without any code changes. I'll revisit and update this after the WWDC keynote, based on new official information that may be made available. |
|
It's official. (One source: https://www.wired.com/story/wwdc-2020-everything-apple-announced/) |
|
It is! Apple has announced it during the WWDC20 keynote. Here are more sources: The timeline they've announced is that it'll be a 2 year transition, with the first Apple Silicon Macs shipping by the end of the year and development kits this week. There will be more Intel-powered macOS devices coming out too. I believe with this information, the plan to update release notes for Go 1.15 mentioned in #38485 (comment) is still valid. All other changes can wait until the tree re-opens for 1.16 development. Feedback is welcome. I plan to send a CL for the release note entry for review this week. |
|
It's possible the new "Apple Silicon" will be a superset of 64-bit ARM, or even a departure. Perhaps a new GOARCH symbol should be considered if that's the case, e.g. |
|
We'll cross that bridge when we come to it. (It seems fairly unlikely that Apple would stop running existing programs. If they introduce new instructions that we care about, we can address that through a |
|
Apple just announced in their State of the Union talk at WWDC that they've developed patches for Go, that they hope to submit in the coming days. So exciting! Hope we can onboard support for macOS/arm64 (even on a branch) very soon. :) |
|
@jpap Thanks for the heads up. A recording of that talk is available at https://developer.apple.com/videos/play/wwdc2020/102/. The phrase I heard around the 20:34 mark is a less definitive "we've already done the initial work for some of the more widely used open-source projects", so we may need to wait to learn details. |
That's right, with the statement that followed: "...and we will be publishing patches to them in the next days". You can see a reference to the Go project on the slide behind the speaker. Now I've only just noticed the bold type on some projects on the second slide below -- perhaps Apple will focus on those first, for which Go may have to wait.
|
|
I don't believe we have to do anything in the Go 1.15 release notes. |
I just want to mention that gomobile is not the only way to build Go programs on iOS. There are probably other tools (not sure if they have ios tag set). Also it could be done by hand (only using Go tools). (I'm not suggesting we should or should not do anything for it in Go 1.15.) |
|
Go 1.15.x does not support macOS/ARM64 port, only tip (Go1.16-to-be) does. For the moment, you may want to use the version mentioned at #42684 (comment), to incorporate some ongoing work. |
|
Also, in case it helps anyone, I've written a fairly rough walkthrough on compiling Go for the M1 entirely on the M1 itself: https://gist.github.com/Dids/dbe6356377e2a0b0dc8eacb0101dc3a7 The process is fairly straightforward, but after spending a few days scratching my head due to various issues (3rd party terminals running in x86 mode for example), this is the best I could come up with. |
On macOS/ARM64, the kernel requires that binaries must have a valid code signature to run. The C toolchain code-signs the binary at link time. We do the same. It is more subtle for Go because we stamp the buildid after linking. As the signature contains hashes of the entire file (except the signature itself), we must (re)generate the signature after stamping the buildid. This CL adds a new codesign package, which provides functionality to generate the code signature. It is a separate internal package so it can be used both in the linker and by the go command. The next CLs will add code-signing to the linker and the go command. Updates #38485, #42684. Change-Id: Id46801a6665beebaab0eb413ff2e64c5b9467059 Reviewed-on: https://go-review.googlesource.com/c/go/+/272254 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
The code signature contains hashes of the entire file (except the signature itself), including the buildid. Therefore, the buildid cannot depend on the signature. Otherwise updating buildid will invalidate the signature, and vice versa. As we cannot change the code-signing algorithm, we can only change buildid calculation. This CL changes the buildid calculation to exclude the Mach-O code signature. So updating code signature after stamping the buildid will not invalidate the buildid. Updates #38485, #42684. Change-Id: I8a9e2e25ca9dc00d9556d13b81652f43bbf6a084 Reviewed-on: https://go-review.googlesource.com/c/go/+/272255 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
This CL lets the linker code-sign output binaries on darwin/arm64, as the kernel requires binaries must be signed in order to run. This signature will likely be invalidated when we stamp the buildid after linking. We still do it in the linker, for - plain "go tool link" works. - the linker generates the LC_CODE_SIGNATURE load command with the right size and offset, so we don't need to update it when stamping the buildid. Updates #38485, #42684. Change-Id: Ia306328906d73217221ba31093fe61a935a46122 Reviewed-on: https://go-review.googlesource.com/c/go/+/272256 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
…ldid As the code signature contains hashes of the entire file (except the signature itself), rewriting buildid will invalidate the signature. This CL makes it regenerate the signature when rewriting the buildid. It only does it when the file already has a code signature, with proper size (darwin/arm64 binaries generated by the Go linker should have). Updates #38485, #42684. Change-Id: I082d9e5808b0ee6a35f9c362d7262aadd9113c81 Reviewed-on: https://go-review.googlesource.com/c/go/+/272257 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Apparently, the darwin kernel may cache the code signature at mmap. When we mmap the output buffer, it doesn't have a code signature (as we haven't generated one). Invalidate the kernel cache after writing the file. See #42684 (comment) for more information. Updates #38485. Fixes #42684. Change-Id: Iac2ef756ca1454c856944423e5040b8e17a6b420 Reviewed-on: https://go-review.googlesource.com/c/go/+/272258 Trust: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
|
CLs for #42684 are in. Now it should work at tip (without checking out https://go.googlesource.com/go/refs/changes/58/272258/1 ). |
|
|
|
Hmmm, I cannot reproduce the ExampleFrames failure. Maybe try again? |
|
Can confirm I'm also getting these errors when building for |
|
@makeworld-the-better-one Go 1.15.x does not support macOS/ARM64 port (see #38485 (comment)). Use tip of the master branch. |
|
As Go 1.16 beta is released, now macOS ARM64 binary release can be downloaded at https://golang.org/dl/#go1.16beta1 . |
|
Problem: #43371 with ios/arm64 executables, the will not execute on iOS devices without I think this should be fixed. |
|
Everyone probably knows this, but for anyone who comes across this in the future, Go 1.16 was released today with non-prerelease, first-class support for |
and others
The ARM-based Mac rumors of the past couple years continue to heat up (e.g. https://www.theverge.com/2020/3/27/21196611/arm-macbook-desktop-apple-2021-release-date)
Has anybody given any thought to what we're going to do with runtime.GOOS and runtime.GOARCH if/when that happens, so we don't add ambiguity between
darwin/arm64(which currently means iOS only) anddarwin/arm64(which might also mean macOS in the future)?Changing GOARCH seems out.
Adding
GOOS=macoswould break any code that switches on those values.Perhaps some magic behavior like we did for
GOOS=android(implieslinuxbuild tags) andGOOS=illumos(impliessolarisbuild tags)? But what would still break code that checksruntime.GOOS.Perhaps keep
darwin/arm64on both iOS and macOS but add some someruntimeexportedconst DarwinOS = {"macos", "ios", ""}that people could switch on when it matters?If there's new API, might be nice to get that in earlier. But OTOH, don't want to jump the gun if rumors don't pan out.
The text was updated successfully, but these errors were encountered: