go: Go 1.16 beta1: ios/amd64 build fails

What version of Go are you using (go version)?

$ go version
go version go1.16beta1 darwin/amd64

What did you do?

I have a cross-compilation test which I run on CI. It builds a binary for all supported GOOS / GOARCH combinations (as reported by go tool dist list).

Using Go 1.15.x, GOOS=ios GOARCH=amd64 is unsupported:

cmd/go: unsupported GOOS/GOARCH pair ios/amd64

Go 1.16 apparently adds support, but building fails. On my Mac, the error message is the following:

❯ GOOS=ios GOARCH=amd64 go build example/main.go
# command-line-arguments
loadinternal: cannot find runtime/cgo

On CI (GitHub Actions), I’m getting the following failure:

# command-line-arguments
loadinternal: cannot find runtime/cgo
/opt/hostedtoolcache/go/1.16.0-beta1/x64/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/bin/ld: cannot find 1144: No such file or directory
/tmp/go-link-046955828/go.o: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status

Not sure what exactly this means, nor do I particularly care about building for this architecture. However, if go tool dist list lists this as a support combination, I would have expected the build to succeed.

What did you expect to see?

go build should succeed.

What did you see instead?

go build failed, see above.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 23 (17 by maintainers)

Commits related to this issue

Most upvoted comments

@churrymui Yes CGO_ENABLED=1 GOOS=ios GOARCH=amd64 go build works.

The main issue is that GOOS=ios GOARCH=amd64 go build gives a really weird error - so it would be better to print out CGO_ENABLED=1 is required for ios/amd64 or alternatively add CGO_ENABLED=1 automatically.

Erroring sounds less “risky” because it can be made to work later.

Yeah, I think it shouldn’t be hard to make internal linking work for iOS, then you don’t need the C linker. Maybe in Go 1.17. Not sure it is that useful, though, since for actual iOS apps I think it generally needs some C (or other language) part.

That said, I think it’s been the case for quite a while (CGO_ENABLED stuff for cross-compilation). As we’re late in the release cycle, maybe it’s better to do the erroring behavior in Go 1.17. This probably will be in cmd/go, but I’m not sure exactly where. Issue #31544 might be relevant (about the loadinternal message).