Build of Go's runtime package fails when cross-compiling with go1.9.4
Closed this issue ยท 6 comments
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.
Also happening here with go1.10.
this is now particularly important because the 1.8.X branch seems to have been removed from docker hub.
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
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
This still seems to fail with go1.10, see https://travis-ci.org/andig/gosdm630/jobs/377325643 for an example.
Since go1.11 features module support, this is no longer an issue.