Build of Go's runtime package fails when cross-compiling with go1.9.4

[ghost]

Cross-compiling a program that depends on Go's runtime package using the following compilation flags on a amd64/Linux system:

CGO_ENABLED=0 GOOS=freebsd GOARCH=amd64

It works when just using gb build for my native platform.

To reproduce: Compile this sample program from the Go runtime example with the following directory structure:

src
|__ app
    |__ main.go

GOROOT=/path/to/go1.9.2 CGO_ENABLED=0 GOOS=freebsd GOARCH=amd64 gb build works. GOROOT=/path/to/go1.9.4 CGO_ENABLED=0 GOOS=freebsd GOARCH=amd64 gb build fails with the error:

# runtime
cgo.go:9:3: //go:cgo_export_static main only allowed in cgo-generated code

According to Ian Lance Taylor, this error was newly introduced in Go 1.9.4. See: https://groups.google.com/forum/#!topic/golang-nuts/52ZHzgo6u1k

Edit: This is with a freshly-built version of gb, built with go 1.9.4.

[dropwhile]

Also happening here with go1.10.

[rbucker]

this is now particularly important because the 1.8.X branch seems to have been removed from docker hub.

[Maykonn]

I fixed it on Ubuntu as follow:

Type go version on cli. If you have any version of go installed, remove it: sudo apt-get remove golang-go

And installing the latest version of Go(currently 1.10) following these steps:

• Download Go: https://golang.org/doc/install?download=go1.10.1.linux-amd64.tar.gz
• And:

  mkdir $HOME/go`
  tar -C $HOME/go -xzf go1.10.1.linux-amd64.tar.gz`
  export GOROOT=$HOME/go
  export GOPATH=/var/www/go
  export PATH=$PATH:$GOROOT/bin

You can set any directory as your GOROOT(the Go directory) and GOPATH(your Go workspace) as you prefer (I set these vars in my .bashrc file).

Verify your Go version with go version and test your installation as explained in this link: https://golang.org/doc/install#testing

[tianon]

this is now particularly important because the 1.8.X branch seems to have been removed from docker hub.

@rbucker if you're referring to the tags of https://hub.docker.com/_/golang/, that's not accurate -- they're no longer supported, which means they'll no longer receive image rebuilds, but the tags are still very much available:

$ docker pull golang:1.8
1.8: Pulling from library/golang
Digest: sha256:f0b5dab7581eddb49dabd1d1b9aa505ca3edcdf79a66395b5bfa4f3c036b49ef
Status: Image is up to date for golang:1.8

$ docker run --rm golang:1.8 go version
go version go1.8.7 linux/amd64

In fact, you can go at least as far back as Go 1.2:

$ docker pull golang:1.2
1.2: Pulling from library/golang
a3ed95caeb02: Already exists 
5d3df020ecd3: Already exists 
067b95d26410: Already exists 
9f482ce8050c: Already exists 
75f31ee85880: Already exists 
8d69f242035f: Already exists 
cd80c24f4996: Already exists 
Digest: sha256:d6b13df58f0156b21f25a23fa74de59489de5336d2c1290ac00611868203e52d
Status: Image is up to date for golang:1.2

$ docker run --rm golang:1.2 go version
go version go1.2.2 linux/amd64

[andig]

This still seems to fail with go1.10, see https://travis-ci.org/andig/gosdm630/jobs/377325643 for an example.

[ghost]

Since go1.11 features module support, this is no longer an issue.