-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
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.) |
|
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 |
Change https://golang.org/cl/344069 mentions this issue: |
ARM64 makes for a better pretty string for the "arm64" architecture. It's more clear that it's 64-bit, and it's closer to what we almost always say. Thanks to Cherry for making this suggestion. For golang/go#38485. For golang/go#36439. Change-Id: I89c175ea2bafce6f191ae797ed982c73962ee5da Reviewed-on: https://go-review.googlesource.com/c/website/+/344069 Trust: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
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=macos
would break any code that switches on those values.Perhaps some magic behavior like we did for
GOOS=android
(implieslinux
build tags) andGOOS=illumos
(impliessolaris
build tags)? But what would still break code that checksruntime.GOOS
.Perhaps keep
darwin/arm64
on both iOS and macOS but add some someruntime
exportedconst 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: