x/playground: exec: "gcc": executable file not found in $PATH

[bradfitz]

I'm getting errors looking for gcc (!?) on the playground:

https://play.golang.org/p/5GlPtcESJm

# net
exec: "gcc": executable file not found in $PATH
Go vet exited.

/cc @andybons

[ysmolski]

Reproduced this in local docker image.
"go vet -x" wants to do this:

mkdir -p $WORK/b067/
cd /usr/local/go/src/net
CGO_LDFLAGS='"-g" "-O2"' /usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/b067/ -importpath net -- -I $WORK/b067/ -g -O2 ./cgo_linux.go ./cgo_resnew.go ./cgo_socknew.go ./cgo_unix.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true

but it fails on gcc line.

Why does vet compile net package in cgo mode while we have CGO_ENABLED=0 set in Dockerfile?

[ysmolski]

Changing from "go vet" to "go tool vet" in vet.go fixes problem in my local machine. Some day I might learn what is the difference between those.

[ysmolski]

And another fix would be:

	cmd := exec.Command("go", "vet", in)
	cmd.Env = append(cmd.Env, "CGO_ENABLED=0")

Meaning that "go vet" does not remember CGO_ENABLED variable set during the build of go tools.

[ianlancetaylor]

If the Go toolchain was built with CGO_ENABLED=0, then that should be the default for go vet. Can you find out what the generated file go/build/zcgo.go looks like? What is the value of defaultCGO_ENABLED in that file?

[ysmolski]

Playground tools are compiled this way:

• CGO_ENABLED=0
• curl -sSL https://dl.google.com/go/go$GO_VERSION.linux-amd64.tar.gz -o /tmp/go.tar.gz
• unpacked to /usr/local
• RUN cp -R /usr/local/go $GOROOT_BOOTSTRAP
• cd /usr/local/go/src && GOOS=nacl GOARCH=amd64p32 ./make.bash --no-clean

Is src/go/build/zcgo.go modified during tools rebuild?

/usr/local/go# cat VERSION
go1.10.2
/usr/local/go# cat src/go/build/zcgo.go
// Code generated by go tool dist; DO NOT EDIT.

package build

const defaultCGO_ENABLED = ""

var cgoEnabled = map[string]bool{
	"android/386": true,
	"android/amd64": true,
	"android/arm": true,
	"android/arm64": true,
	"darwin/386": true,
	"darwin/amd64": true,
	"darwin/arm": true,
	"darwin/arm64": true,
	"dragonfly/amd64": true,
	"freebsd/386": true,
	"freebsd/amd64": true,
	"linux/386": true,
	"linux/amd64": true,
	"linux/arm": true,
	"linux/arm64": true,
	"linux/mips": true,
	"linux/mips64": true,
	"linux/mips64le": true,
	"linux/mipsle": true,
	"linux/ppc64le": true,
	"linux/s390x": true,
	"netbsd/386": true,
	"netbsd/amd64": true,
	"netbsd/arm": true,
	"openbsd/386": true,
	"openbsd/amd64": true,
	"solaris/amd64": true,
	"windows/386": true,
	"windows/amd64": true,
}

[ianlancetaylor]

The zcgo.go file is created while running make.bash (by mkzcgo in cmd/dist/build.go) and should never be modified afterward. Seeing defaultCGO_ENABLED set to the empty string suggests that CGO_ENABLED was not set (or was set to the empty string) when make.bash was run. I can't tell from the above: is CGO_ENABLED=0 expected to be set while running make.bash? If so, I can't explain what you are seeing.

[ysmolski]

Then I expect defaultCGO_ENABLED=“0” because when I try this directly without docker it works as expected. I suspect that Docker magic (ENV CGO_ENABLED=0) prevents the expected behaviour.

…

On 10-07-2018, at 19:59, Ian Lance Taylor ***@***.***> wrote: The zcgo.go file is created while running make.bash (by mkzcgo in cmd/dist/build.go) and should never be modified afterward. Seeing defaultCGO_ENABLED set to the empty string suggests that CGO_ENABLED was not set (or was set to the empty string) when make.bash was run. I can't tell from the above: is CGO_ENABLED=0 expected to be set while running make.bash? If so, I can't explain what you are seeing. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#26307 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIj1QmTR30ga4LIUvwMB5ID5O-nPh6Kks5uFN1agaJpZM4VIqmy>.

[ysmolski]

Running vet directly in the docker image:

root@58a9d65c6c00:/go/src/s# go vet net.go
# net
exec: "gcc": executable file not found in $PATH
root@58a9d65c6c00:/go/src/s# go tool vet net.go
root@58a9d65c6c00:/go/src/s# GOOS=nacl GOARCH=amd64p32 go vet net.go
root@58a9d65c6c00:/go/src/s# GOOS=nacl GOARCH=amd64p32 go tool vet net.go

It was built this way:

ENV CGO_ENABLED=0
<<skipped>>
# Get the Go binary.
RUN curl -sSL https://dl.google.com/go/go$GO_VERSION.linux-amd64.tar.gz -o /tmp/go.tar.gz
RUN curl -sSL https://dl.google.com/go/go$GO_VERSION.linux-amd64.tar.gz.sha256 -o /tmp/go.tar.gz.sha256
RUN echo "$(cat /tmp/go.tar.gz.sha256) /tmp/go.tar.gz" | sha256sum -c -
RUN tar -C /usr/local/ -vxzf /tmp/go.tar.gz
# Make a copy for GOROOT_BOOTSTRAP, because we rebuild the toolchain and make.bash removes bin/go as its first step.
RUN cp -R /usr/local/go $GOROOT_BOOTSTRAP
# Apply the fake time and fake filesystem patches.
RUN patch /usr/local/go/src/runtime/rt0_nacl_amd64p32.s /usr/local/playground/enable-fake-time.patch
RUN patch -p1 -d /usr/local/go </usr/local/playground/strict-time.patch
RUN cd /usr/local/go && go run misc/nacl/mkzip.go -p syscall /usr/local/playground/fake_fs.lst src/syscall/fstest_nacl.go
# Re-build the Go toolchain.
RUN cd /usr/local/go/src && GOOS=nacl GOARCH=amd64p32 ./make.bash --no-clean

Here we cross compile go and toolchain, but I am not sure if the native go is getting recompiled too using CGO_ENABLED=0. It seems it is not, but the it looks like it's datetime is get updated:

root@58a9d65c6c00:/usr/local/go/bin# ls -l
total 29728
-rwxr-xr-x 1 root root 11235730 Jul 10 17:06 go
-rwxr-xr-x 1 root root 15727868 Apr 30 20:34 godoc
-rwxr-xr-x 1 root root  3468455 Jul 10 17:06 gofmt
drwxr-xr-x 2 root root     4096 Jul 10 17:07 nacl_amd64p32

[ianlancetaylor]

My guess is that because you are running make.bash --no-clean the existing go/build package, which was built without CGO_ENABLED being set, is reused. So although you do get a new go command, it is still one that defaults to CGO_ENABLED unset, and therefore defaults to actually using cgo.

[ianlancetaylor]

In any case explicitly setting CGO_ENABLED=0 when running go vet seems appropriate. It may also be appropriate to set GOOS and GOARCH.

[gopherbot]

Change https://golang.org/cl/123136 mentions this issue: playground: disable cgo in the vet tool