go version)?$ go version go version go1.12.7 darwin/amd64
go env)?go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/andig/htdocs/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/opt/go/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/mbmd/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-build085038192=/tmp/go-build -gno-record-gcc-switches -fno-common"
Run cross-build of
GOARCH=arm GOARM=6 make build
Clean build
OSX:
Generating embedded assets
go generate ./...
# golang.org/x/tools/cmd/stringer
runtime.save_g: relocation target runtime.read_tls_fallback not defined
runtime.load_g: relocation target runtime.read_tls_fallback not defined
runtime._initcgo: relocation target runtime.read_tls_fallback not defined
meters/measurements.go:23: running "go": exit status 2
# github.com/mjibson/esc
runtime.save_g: relocation target runtime.read_tls_fallback not defined
runtime.load_g: relocation target runtime.read_tls_fallback not defined
runtime._initcgo: relocation target runtime.read_tls_fallback not defined
server/http.go:21: running "go": exit status 2
make: *** [assets] Error 1
Travis (go version go1.12 linux/amd64)
go generate ./...
fork/exec /tmp/go-build169921720/b001/exe/stringer: exec format error
meters/measurements.go:23: running "go": exit status 1
fork/exec /tmp/go-build179584689/b001/exe/doc: exec format error
server/http.go:21: running "go": exit status 1
make: *** [Makefile:27: assets] Error 1
The command '/bin/sh -c GOARCH=arm GOARM=6 make build' returned a non-zero code: 2
My feeling (nothing more) is that is a recent problem as I was able to cross-build using stringer before on other projects. For sake of reference there's an entire build log in https://travis-ci.org/volkszaehler/mbmd.
Update: trying without GOARM I get:
````
❯ GOARCH=arm make build
Generating embedded assets
go generate ./...
/usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: warning: ignoring file /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-link-125095315/go.o, file was built for armv7 which is not the architecture being linked (x86_64): /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-link-125095315/go.o
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
````
To be clear, you are running make build on https://github.com/volkszaehler/mbmd ?
cc @ianlancetaylor @randall77
Exactly. Out of that is is specifically
go generate ./...
that fails. I could try bisecting older go versions?
There is some sort of problem, but it's hard to tell where exactly it is.
First, what kind of architecture are you using? In the issue title you say ARM, but in the "go version" output I see "darwin/amd64". Are you on a Mac?
To confirm whether cmd/stringer is involved or not, can you try building it directly?
go build golang.org/x/tools/cmd/stringer
First, what kind of architecture are you using? In the issue title you say ARM, but in the "go version" output I see "darwin/amd64". Are you on a Mac?
I ran into the problem on travis-ci and later saw something similar on OSX, hence the double report. Here are some things I've tried on OSX:
❯ go version
go version go1.12.7 darwin/amd64
❯ go generate ./...
❯ GOARCH=arm go generate ./...
# golang.org/x/tools/cmd/stringer
/usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: warning: ignoring file /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-link-714679626/go.o, file was built for armv7 which is not the architecture being linked (x86_64): /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-link-714679626/go.o
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
meters/measurements.go:23: running "go": exit status 2
# github.com/mjibson/esc
/usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: warning: ignoring file /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-link-536613157/go.o, file was built for armv7 which is not the architecture being linked (x86_64): /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-link-536613157/go.o
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
server/http.go:21: running "go": exit status 2
❯ GOOS=linux GOARCH=amd64 go build golang.org/x/tools/cmd/stringer
❯ GOOS=linux GOARCH=arm go build golang.org/x/tools/cmd/stringer
❯ GOOS=linux GOARCH=ARM go build golang.org/x/tools/cmd/stringer
cmd/go: unsupported GOOS/GOARCH pair linux/ARM
but
❯ GOOS=linux GOARCH=arm make build
Generating embedded assets
go generate ./...
fork/exec /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-build317921363/b001/exe/stringer: exec format error
meters/measurements.go:23: running "go": exit status 1
fork/exec /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-build548060984/b001/exe/doc: exec format error
server/http.go:21: running "go": exit status 1
make: *** [assets] Error 1
and
❯ GOOS=linux GOARCH=arm go generate ./...
fork/exec /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-build027256891/b001/exe/stringer: exec format error
meters/measurements.go:23: running "go": exit status 1
fork/exec /var/folders/w5/_c0nb6n90fn96tzw04dtc6240000gn/T/go-build880784254/b001/exe/doc: exec format error
server/http.go:21: running "go": exit status 1
So cross-building stringer is fine but using it during go generate isn't?
The go:generate comments in https://github.com/volkszaehler/mbmd are
//go:generate go run golang.org/x/tools/cmd/stringer -type=Measurement
//go:generate go run github.com/mjibson/esc -private -o assets.go -pkg server -prefix ../assets ../assets
You are explicitly invoking go run. Setting GOARCH in the environment is telling go run to build a binary that runs on ARM. The stringer binary requires external linking for some reason (I haven't looked) but you are using a native compiler rather than an ARM cross-compiler. That is why you are getting the error you are getting. Even if the stringer binary didn't require external linking, the operation would still fail as your system cannot run a binary built for ARM.
The usual approach, the one used in, for example, the Go standard library, is to run go install golang.org/x/tools/cmd/stringer and use go:generate comments that look like
//go:generate stringer -type=Measurement
If you choose to write your go:generate comments to use go run, I'm not sure if there is a reasonable way to fix this.
I'm sorry, feeling ashamed and stupid. Still- while closing this as invalid- I'd still be interested in how to properly install build dependencies. I do have a tools.go:
// +build tools
package mbmd
import (
_ "github.com/mjibson/esc"
_ "golang.org/x/tools/cmd/stringer"
)
but that doesn't seem to suffice to make the executables available for build:
meters/measurements.go:23: running "stringer": exec: "stringer": executable file not found in $PATH
server/http.go:21: running "esc": exec: "esc": executable file not found in $PATH
Makefile:26: recipe for target 'assets' failed
Would be great to round this off for other potential users.
EDIT
OK, guess I've found that mistake, too: package was mbmd while it should have been main. After changing to main it seems to work. A but confusing since go didn't raise an error about conflicting package names in this case.
No reason to feel ashamed or stupid, it was a perfectly reasonable question.
Most helpful comment
No reason to feel ashamed or stupid, it was a perfectly reasonable question.