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

$ go version
go version go1.19.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/brian/.cache/go-build"
GOENV="/home/brian/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/brian/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/brian/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.3"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/brian/repro/go.mod"
GOWORK=""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2864122989=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This is tested inside an Ubuntu 22.04 lxd container, started from images:ubuntu/22.04/cloud. This provides the "ubuntu-minimal" distribution, which doesn't have gcc / build-essential packages installed by default.

-- go.mod --
module example.com/repro

go 1.19

-- main.go --
package main

import _ "net/http"

func main() {
}

-- main_test.go --
package main

import "testing"

func TestFoo(t *testing.T) {
}

Then in this directory:

$ go run .
$ go test .
$ go vet .

What did you expect to see?

All these commands to succeed.

What did you see instead?

go build . succeeds, but go test . and go vet . fail.

$ go build .
$ go test .
# runtime/cgo
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH
FAIL	example.com/repro [build failed]
FAIL
$ go vet .
# runtime/cgo
cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in $PATH
$ 

Additional info

I have found that:

• go test -vet=off . works
• If you comment out the import of net/http, then go test . works.
• If you change the import from net/http to net/netip, then go test . works
• If you change the import from net/http to net, then go test . still fails
• Running go mod tidy makes no difference

Therefore this appears to be something to do with importing specific net libraries in the presence of go vet

I expect most people don't notice this because most developers do have gcc installed.

Workaround

CGO_ENABLED=0 go test .

or:

go test -vet=off .

I don't like the first option, because it makes me worry that the artefact from go build is different to the one being tested. I guess I could also use CGO_ENABLED=0 go build . to ensure the build product is consistent.

I don't like the second one because I lose the vet checks.

But splitting vet and test looks to be a reasonable solution:

CGO_ENABLED=0 go vet
go test -vet=off .

Linked / related issues

Forked from #28065 on request. See also #27639, #27303.

This new issue removes any ambiguity around Alpine Linux / musl libc or GOPATH mode; neither is relevant.