Description
What version of Go are you using (go version
)?
golang:1.11.1-alpine3.8:
go version go1.11.1 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env
)?
Also from that docker image:
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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=/tmp/go-build610617865=/tmp/go-build -gno-record-gcc-switches"
What did you do?
Run go test
on a simple package that imports some network packages like net/http
. Expect it to work, even when I don't have gcc
installed, which is the case with the Alpine Go images. This worked on 1.10. It broke when we switched to the 1.11 images.
Here is a simple reproducer script:
docker run -i golang:1.11.1-alpine3.8 sh <<-SCRIPT
mkdir -p src/foo.com/bar
cd src/foo.com/bar
cat <<EOF >main.go
package main
import _ "net/http"
func main() {}
EOF
go test
SCRIPT
What did you expect to see?
What I see if I use golang:1.11.1-stretch
:
$ ./repro.sh
? foo.com/bar [no test files]
Note that this has nothing to do with the package not having test files or tests. We encountered this on a package that has plenty of tests.
What did you see instead?
$ ./repro.sh
# runtime/cgo
exec: "gcc": executable file not found in $PATH
Also note that we are not in module-aware mode, so this issue should be different from #26988. I believe this is the same issue that @mfridman and @tylercloke were reporting in that thread.
For the time being, we've just globally set CGO_ENABLED=0
on all of our CI jobs, since we don't use CGO on our production builds anyway. And one could argue that we should have been doing that from the start anyway. Nonetheless, this still seems like a bug or some sort of regression to me.
Activity
mvdan commentedon Oct 7, 2018
Forgot to mention - the stretch image does have gcc, while the alpine image does not.
adamdecaf commentedon Oct 7, 2018
This might be better classified as "the official golang:alpine images should install a supported libc" .
From #27264 (comment)
mvdan commentedon Oct 7, 2018
I don't think this is related. I'm not having any issues with Alpine's musl libc, and Go does otherwise work.
If the official Go docker image based on Alpine required installing glibc, what would be the point of distributing that image to begin with?
FiloSottile commentedon Oct 9, 2018
Also, I don't think we make any statement as to requiring glibc for Go to work if properly built. That comment is about the Go binary distribution.
palsivertsen commentedon Oct 10, 2018
Looks like a dupe of #27639
mtibben commentedon Oct 12, 2018
I think this issue should stay open to describe the
go test
issue as opposed to thego build
issue. See #26988 (comment).mtibben commentedon Oct 12, 2018
I'm also seeing this behaviour when running
go test
on Windows (no gcc)mvdan commentedon Oct 12, 2018
There have been a bunch of related issues, some being fixed and some being closed as duplicates. Note however, that many of them including #26988 require running the Go command in module-aware mode, while this one doesn't.
It does look like #27639 is a very similar issue, but that was closed and didn't have much activity, so I think we should keep this one open for now.
rsc commentedon Oct 24, 2018
There's something about the Alpine image that makes the go command think rebuilding is necessary. Does pkg/linux_amd64/runtime/cgo.a even exist in the image?
If the Alpine image were built with CGO_ENABLED=0 then I could see that doing a CGO_ENABLED=1 build would do a rebuild. But I don't see that in the Dockerfile.
https://github.com/docker-library/golang/blob/ed78459fac108dab72556146b759516cc65ee109/1.11/alpine3.8/Dockerfile
palsivertsen commentedon Oct 25, 2018
pkg/linux_amd64/runtime/cgo.a
exists yes.Dump of
runtime
andhttp
files in the docker image:oec commentedon Oct 26, 2018
Maybe this is unrelated to the Alpine image, as I experience the same issue with go 1.11.1 on Ubuntu 18.04.1 LTS, using vanilla go downloaded from https://dl.google.com/go/go1.11.1.linux-amd64.tar.gz.
61 remaining items