Skip to content
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

Closed
bradfitz opened this issue Apr 16, 2020 · 153 comments
Closed

runtime: tracking bug for ARM-based macOS and GOOS/GOARCH values #38485

bradfitz opened this issue Apr 16, 2020 · 153 comments

Comments

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Apr 16, 2020

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) and darwin/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 (implies linux build tags) and GOOS=illumos (implies solaris build tags)? But what would still break code that checks runtime.GOOS.

Perhaps keep darwin/arm64 on both iOS and macOS but add some some runtime exported const 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.

@andybons andybons added this to the Unplanned milestone Apr 16, 2020
@rsc
Copy link
Contributor

@rsc rsc commented Apr 27, 2020

If darwin/arm64 doesn't work for macos,
then I think we should reclaim it for macos
and move ios over to ios/arm64, much as we have
android as an almost-synonym for Linux on mobile.
(Many fewer GOOS=darwin users on mobile than desktop.)

I've thought about whether we should have GOOS=macos
independently of this issue, but it seems like too much churn
for too little benefit.

Interesting to note that way back when, we could have done
GOOS=osx and we'd be in the same boat of having the wrong
name. Moving to GOOS=macos will only match Apple terminology
until the next OS rename.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 1, 2020

I think the suggestion here is:

  1. add ios as a valid GOOS value
  2. let ios imply darwin much as android implies linux

This will potentially break any existing mobile programs that test runtime.GOOS and expect to see darwin. After this change they will see ios.

This suggests that for 1.15 we should

  1. add ios as a valid build tag that implies darwin
  2. announce in the release notes that we plan to change to GOOS=ios in a future release
@ianlancetaylor ianlancetaylor modified the milestones: Unplanned, Go1.15 May 1, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 1, 2020

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented May 1, 2020

I think (but not sure) gomobile sets ios tag, to distinguish iOS emulator on x86 vs. macOS.

@hyangah
Copy link
Contributor

@hyangah hyangah commented May 1, 2020

@dmitshur
Copy link
Member

@dmitshur dmitshur commented May 4, 2020

Interesting to note that way back when, we could have done
GOOS=osx and we'd be in the same boat of having the wrong
name. Moving to GOOS=macos will only match Apple terminology
until the next OS rename.

Also interesting is that Apple currently has macOS, iOS, iPadOS, tvOS, and watchOS.

@hajimehoshi
Copy link
Member

@hajimehoshi hajimehoshi commented May 9, 2020

As far as I know about mobile application developing, there should be no problem to add ios to GOOS :-)

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 22, 2020

Change https://golang.org/cl/239278 mentions this issue: all: experiment with adding ios as a recognized GOOS value and build constraint that implies darwin

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jun 22, 2020

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 ios as a valid build tag that implies darwin" for 1.15, as I understand, is to enable people to start moving their iOS-specific code away from darwin,arm64 to something else as early as 1.15, rather than later. However, as @hyangah mentioned in #38485 (comment), the gomobile tool already sets an "ios" build constraint whenever targeting iOS (see code here, here and here). That means we don't need to make changes in Go 1.15 for people to be able to start moving iOS-specific code behind a potentially more future-proof ios build constraint. They can already do that now, even with Go 1.14, 1.13, etc. (Runtime code that attempts to check runtime.GOOS to tell whether iOS is the target is a separate matter, and I'll address that in a later comment.)

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 amd64. We can also defer any changes to the main tree until we know for certain we need to reclaim darwin,arm64 (as @rsc emphasized in his original comment).

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.

@bradfitz
Copy link
Contributor Author

@bradfitz bradfitz commented Jun 22, 2020

It's official.

(One source: https://www.wired.com/story/wwdc-2020-everything-apple-announced/)

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jun 22, 2020

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.

@networkimprov
Copy link

@networkimprov networkimprov commented Jun 22, 2020

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. apl64?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 22, 2020

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 GOARM64 environment variable if necessary.)

@jpap
Copy link
Contributor

@jpap jpap commented Jun 22, 2020

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. :)

@dmitshur
Copy link
Member

@dmitshur dmitshur commented Jun 22, 2020

@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.

@jpap
Copy link
Contributor

@jpap jpap commented Jun 22, 2020

@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.

image

image

@rsc
Copy link
Contributor

@rsc rsc commented Jun 23, 2020

I don't believe we have to do anything in the Go 1.15 release notes.
Nothing is changing for Go 1.15.

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Jun 24, 2020

the gomobile tool already sets an "ios" build constraint whenever targeting iOS (see code here, here and here). That means we don't need to make changes in Go 1.15 for people to be able to start moving iOS-specific code behind a potentially more future-proof ios build constraint.

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.)

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Nov 30, 2020

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.

@Dids
Copy link

@Dids Dids commented Dec 1, 2020

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.

gopherbot pushed a commit that referenced this issue Dec 1, 2020
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>
gopherbot pushed a commit that referenced this issue Dec 1, 2020
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>
gopherbot pushed a commit that referenced this issue Dec 1, 2020
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>
gopherbot pushed a commit that referenced this issue Dec 1, 2020
…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>
gopherbot pushed a commit that referenced this issue Dec 1, 2020
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>
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Dec 2, 2020

CLs for #42684 are in. Now it should work at tip (without checking out https://go.googlesource.com/go/refs/changes/58/272258/1 ).

@felipecsl
Copy link

@felipecsl felipecsl commented Dec 2, 2020

all.bash failed though:

arch --arm64e env GOROOT_BOOTSTRAP=$GO_TMP/go-darwin-arm64-bootstrap ./all.bash
Building Go cmd/dist using /var/folders/73/8zyvcpds2612pj0nmtwt68_c0000gn/T/go-arm-bootstrap.PB58nt4i/go-darwin-arm64-bootstrap. (devel +cf7aa585ac Tue Dec 1 23:39:15 2020 +0000 darwin/arm64)
Building Go toolchain1 using /var/folders/73/8zyvcpds2612pj0nmtwt68_c0000gn/T/go-arm-bootstrap.PB58nt4i/go-darwin-arm64-bootstrap.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/arm64.

##### Testing packages.
ok  	archive/tar	0.464s
ok  	archive/zip	0.572s
ok  	bufio	0.425s
ok  	bytes	0.533s
ok  	compress/bzip2	0.208s
ok  	compress/flate	0.970s
ok  	compress/gzip	0.543s
ok  	compress/lzw	0.658s
ok  	compress/zlib	0.863s
ok  	container/heap	0.285s
ok  	container/list	0.807s
ok  	container/ring	0.855s
ok  	context	0.678s
ok  	crypto	0.805s
ok  	crypto/aes	0.747s
ok  	crypto/cipher	0.656s
ok  	crypto/des	0.547s
ok  	crypto/dsa	0.723s
ok  	crypto/ecdsa	0.765s
ok  	crypto/ed25519	0.471s
ok  	crypto/elliptic	0.704s
ok  	crypto/hmac	0.492s
ok  	crypto/internal/subtle	0.579s
ok  	crypto/md5	0.678s
ok  	crypto/rand	0.686s
ok  	crypto/rc4	0.722s
ok  	crypto/rsa	0.905s
ok  	crypto/sha1	0.522s
ok  	crypto/sha256	0.604s
ok  	crypto/sha512	0.551s
ok  	crypto/subtle	0.591s
ok  	crypto/tls	1.305s
ok  	crypto/x509	1.077s
ok  	database/sql	0.874s
ok  	database/sql/driver	0.156s
ok  	debug/dwarf	0.203s
ok  	debug/elf	0.167s
ok  	debug/gosym	0.294s
ok  	debug/macho	0.240s
ok  	debug/pe	0.426s
ok  	debug/plan9obj	0.276s
ok  	embed/internal/embedtest	0.405s
ok  	encoding/ascii85	0.438s
ok  	encoding/asn1	0.159s
ok  	encoding/base32	0.186s
ok  	encoding/base64	0.242s
ok  	encoding/binary	0.200s
ok  	encoding/csv	0.171s
ok  	encoding/gob	0.263s
ok  	encoding/hex	0.160s
ok  	encoding/json	0.397s
ok  	encoding/pem	0.200s
ok  	encoding/xml	0.161s
ok  	errors	0.162s
ok  	expvar	0.194s
ok  	flag	0.235s
ok  	fmt	0.400s
ok  	go/ast	0.298s
ok  	go/build	1.393s
ok  	go/constant	0.284s
ok  	go/doc	0.389s
ok  	go/format	0.382s
ok  	go/importer	0.296s
ok  	go/internal/gccgoimporter	0.382s
ok  	go/internal/gcimporter	0.291s
ok  	go/internal/srcimporter	4.194s
ok  	go/parser	0.361s
ok  	go/printer	0.537s
ok  	go/scanner	0.275s
ok  	go/token	0.275s
ok  	go/types	1.547s
ok  	hash	0.183s
ok  	hash/adler32	0.179s
ok  	hash/crc32	0.339s
ok  	hash/crc64	0.209s
ok  	hash/fnv	0.212s
ok  	hash/maphash	0.717s
ok  	html	0.641s
ok  	html/template	0.283s
ok  	image	0.322s
ok  	image/color	0.218s
ok  	image/draw	0.216s
ok  	image/gif	0.555s
ok  	image/jpeg	0.471s
ok  	image/png	0.494s
ok  	index/suffixarray	0.594s
ok  	internal/cpu	0.240s
ok  	internal/fmtsort	0.156s
ok  	internal/poll	0.182s
ok  	internal/profile	0.159s
ok  	internal/reflectlite	0.173s
ok  	internal/singleflight	0.185s
ok  	internal/trace	0.192s
ok  	internal/unsafeheader	0.253s
ok  	internal/xcoff	0.168s
ok  	io	0.294s
ok  	io/fs	0.154s
ok  	io/ioutil	0.401s
ok  	log	0.333s
ok  	log/syslog	1.558s
ok  	math	0.272s
ok  	math/big	0.666s
ok  	math/bits	0.379s
ok  	math/cmplx	0.165s
ok  	math/rand	0.237s
ok  	mime	0.239s
ok  	mime/multipart	0.434s
ok  	mime/quotedprintable	0.445s
ok  	net	1.907s
ok  	net/http	5.836s
ok  	net/http/cgi	1.129s
ok  	net/http/cookiejar	0.182s
ok  	net/http/fcgi	0.189s
ok  	net/http/httptest	0.325s
ok  	net/http/httptrace	0.162s
ok  	net/http/httputil	0.232s
ok  	net/http/internal	0.148s
ok  	net/http/pprof	5.399s
ok  	net/internal/socktest	0.363s
ok  	net/mail	0.194s
ok  	net/rpc	0.220s
ok  	net/rpc/jsonrpc	0.182s
ok  	net/smtp	0.179s
ok  	net/textproto	0.176s
ok  	net/url	0.153s
ok  	os	0.936s
ok  	os/exec	1.325s
ok  	os/signal	2.320s
ok  	os/user	0.301s
ok  	path	0.140s
ok  	path/filepath	0.153s
ok  	plugin	0.167s
ok  	reflect	0.524s
ok  	regexp	0.231s
ok  	regexp/syntax	0.768s
--- FAIL: ExampleFrames (0.00s)
got:
- more:true | runtime.Callers
- more:true | runtime_test.ExampleFrames.func1
- more:true | runtime_test.ExampleFrames.func2
- more:true | runtime_test.ExampleFrames.func3
- more:true | runtime_test.ExampleFrames
- more:true | testing.runExample
- more:true | testing.runExamples
- more:true | testing.(*M).Run
- more:true | runtime_test.TestMain
want:
- more:true | runtime.Callers
- more:true | runtime_test.ExampleFrames.func1
- more:true | runtime_test.ExampleFrames.func2
- more:true | runtime_test.ExampleFrames.func3
- more:true | runtime_test.ExampleFrames
FAIL
FAIL	runtime	68.642s
ok  	runtime/debug	0.186s
ok  	runtime/internal/atomic	0.314s
ok  	runtime/internal/math	0.150s
ok  	runtime/internal/sys	0.174s
ok  	runtime/metrics	0.289s
ok  	runtime/pprof	6.390s
ok  	runtime/race	0.478s
ok  	runtime/trace	0.655s
ok  	sort	0.189s
ok  	strconv	0.403s
ok  	strings	0.250s
ok  	sync	0.568s
ok  	sync/atomic	0.216s
ok  	syscall	0.335s
ok  	testing	0.633s
ok  	testing/fstest	0.218s
ok  	testing/iotest	0.168s
ok  	testing/quick	0.200s
ok  	text/scanner	0.392s
ok  	text/tabwriter	0.316s
ok  	text/template	0.189s
ok  	text/template/parse	0.156s
ok  	time	2.770s
ok  	unicode	0.156s
ok  	unicode/utf16	0.160s
ok  	unicode/utf8	0.182s
ok  	cmd/addr2line	4.773s
ok  	cmd/api	5.862s
ok  	cmd/asm/internal/asm	1.224s
ok  	cmd/asm/internal/lex	0.170s
ok  	cmd/compile	0.202s
ok  	cmd/compile/internal/gc	10.480s
ok  	cmd/compile/internal/logopt	0.210s
ok  	cmd/compile/internal/ssa	0.668s
ok  	cmd/compile/internal/syntax	0.166s
ok  	cmd/compile/internal/test	0.207s
ok  	cmd/compile/internal/types	0.170s
ok  	cmd/cover	3.462s
ok  	cmd/doc	0.358s
ok  	cmd/fix	1.869s
ok  	cmd/go	63.549s
ok  	cmd/go/internal/auth	0.162s
ok  	cmd/go/internal/cache	0.383s
ok  	cmd/go/internal/fsys	0.194s
ok  	cmd/go/internal/generate	0.293s
ok  	cmd/go/internal/get	0.312s
ok  	cmd/go/internal/imports	0.218s
ok  	cmd/go/internal/load	0.183s
ok  	cmd/go/internal/lockedfile	0.228s
ok  	cmd/go/internal/lockedfile/internal/filelock	0.176s
ok  	cmd/go/internal/modconv	0.195s
ok  	cmd/go/internal/modfetch	0.256s
ok  	cmd/go/internal/modfetch/codehost	0.217s
ok  	cmd/go/internal/modfetch/zip_sum_test	0.192s
ok  	cmd/go/internal/modload	0.512s
ok  	cmd/go/internal/mvs	0.189s
ok  	cmd/go/internal/par	0.244s
ok  	cmd/go/internal/renameio	2.166s
ok  	cmd/go/internal/search	0.662s
ok  	cmd/go/internal/str	0.595s
ok  	cmd/go/internal/test	0.364s
ok  	cmd/go/internal/txtar	0.168s
ok  	cmd/go/internal/vcs	0.219s
ok  	cmd/go/internal/web	0.184s
ok  	cmd/go/internal/work	0.481s
ok  	cmd/gofmt	0.202s
ok  	cmd/internal/archive	3.054s
ok  	cmd/internal/buildid	0.374s
ok  	cmd/internal/dwarf	0.336s
ok  	cmd/internal/edit	0.418s
ok  	cmd/internal/goobj	1.053s
ok  	cmd/internal/moddeps	7.314s
ok  	cmd/internal/obj	0.603s
ok  	cmd/internal/obj/arm64	0.433s
ok  	cmd/internal/obj/ppc64	0.453s
ok  	cmd/internal/obj/riscv	0.318s
ok  	cmd/internal/obj/s390x	0.149s
ok  	cmd/internal/obj/x86	7.075s
ok  	cmd/internal/objabi	0.196s
ok  	cmd/internal/pkgpath	0.273s
ok  	cmd/internal/src	0.142s
ok  	cmd/internal/sys	0.206s
ok  	cmd/internal/test2json	0.339s
ok  	cmd/link	8.938s
ok  	cmd/link/internal/benchmark	0.498s
ok  	cmd/link/internal/ld	13.037s
ok  	cmd/link/internal/loader	0.310s
ok  	cmd/nm	5.512s
ok  	cmd/objdump	8.401s
ok  	cmd/pack	4.955s
ok  	cmd/trace	0.613s
ok  	cmd/vet	21.658s
FAIL
go tool dist: Failed: exit status 1
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Dec 2, 2020

Hmmm, I cannot reproduce the ExampleFrames failure. Maybe try again?

@makeworld-the-better-one
Copy link

@makeworld-the-better-one makeworld-the-better-one commented Dec 6, 2020

#38485 (comment)

Can confirm I'm also getting these errors when building for darwin/arm64 on 64-bit Linux, with Go version 1.15.5

/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/tmp/go-link-303716583/go.o: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status
@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Dec 7, 2020

@makeworld-the-better-one Go 1.15.x does not support macOS/ARM64 port (see #38485 (comment)). Use tip of the master branch.

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Dec 17, 2020

As Go 1.16 beta is released, now macOS ARM64 binary release can be downloaded at https://golang.org/dl/#go1.16beta1 .

@enty8080
Copy link

@enty8080 enty8080 commented Dec 24, 2020

@cherrymui

Problem: #43371 with ios/arm64 executables, the will not execute on iOS devices without specified min version.

I think this should be fixed.

@skyzyx
Copy link

@skyzyx skyzyx commented Feb 16, 2021

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 darwin/arm64. https://golang.org/doc/go1.16#darwin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet