New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: 'go test' on alpine requires gcc in GOPATH mode #28065

Open
mvdan opened this Issue Oct 7, 2018 · 15 comments

Comments

Projects
None yet
10 participants
@mvdan
Member

mvdan commented Oct 7, 2018

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.

/cc @bcmills @thepudds @myitcv

@mvdan mvdan added this to the Go1.12 milestone Oct 7, 2018

@mvdan

This comment has been minimized.

Member

mvdan commented Oct 7, 2018

Forgot to mention - the stretch image does have gcc, while the alpine image does not.

@adamdecaf

This comment has been minimized.

Contributor

adamdecaf commented Oct 7, 2018

This might be better classified as "the official golang:alpine images should install a supported libc" .

From #27264 (comment)

The official Go binaries are known to not work on Alpine because we assume glibc. That is #18773 and #19938.

Are you saying that the Go binary from go get golang.org/dl/go1.10.3 but not from go get golang.org/dl/go1.11? Or did you get your go1.10.3 from somewhere else? (e.g. from Alpine apk)

@mvdan

This comment has been minimized.

Member

mvdan commented 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

This comment has been minimized.

Member

FiloSottile commented 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

This comment has been minimized.

palsivertsen commented Oct 10, 2018

Looks like a dupe of #27639

@mtibben

This comment has been minimized.

mtibben commented Oct 12, 2018

I think this issue should stay open to describe the go test issue as opposed to the go build issue. See #26988 (comment).

@mtibben

This comment has been minimized.

mtibben commented Oct 12, 2018

I'm also seeing this behaviour when running go test on Windows (no gcc)

@mvdan

This comment has been minimized.

Member

mvdan commented 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

This comment has been minimized.

Contributor

rsc commented 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

This comment has been minimized.

palsivertsen commented Oct 25, 2018

pkg/linux_amd64/runtime/cgo.a exists yes.

Dump of runtime and http files in the docker image:

# tree pkg/linux_amd64/runtime* pkg/linux_amd64/net/http* pkg/linux_amd64/vendor/golang_org/x/net/http*
pkg/linux_amd64/runtime
├── cgo.a
├── debug.a
├── internal
│   ├── atomic.a
│   └── sys.a
├── pprof
│   └── internal
│       └── profile.a
├── pprof.a
├── race.a
└── trace.a
pkg/linux_amd64/runtime.a [error opening dir]
pkg/linux_amd64/net/http
├── cgi.a
├── cookiejar.a
├── fcgi.a
├── httptest.a
├── httptrace.a
├── httputil.a
├── internal.a
└── pprof.a
pkg/linux_amd64/net/http.a [error opening dir]
pkg/linux_amd64/vendor/golang_org/x/net/http
├── httpguts.a
└── httpproxy.a
pkg/linux_amd64/vendor/golang_org/x/net/http2
└── hpack.a

3 directories, 19 files
@oec

This comment has been minimized.

oec commented 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.

stevendanna added a commit to chef/scaffolding-go that referenced this issue Nov 16, 2018

Bump scaffolding-go, pulling in Go 1.11
This unpins our version of core/scaffolding-go which in turn will pull
in the latest version of core/go.

All of A2 builds and passes tests with this change in place:

https://buildkite.com/chef/chef-a2-master-verify/builds/17409

In the past we had pinned our version of Go to avoid this bug:

golang/go#28065

However, rather than pinning, we should track down any places where
that is still an issue and either make sure those builds either have
gcc available or set GCO_ENABLED=0.

Signed-off-by: Steven Danna <steve@chef.io>
@ArtoriaRen

This comment has been minimized.

ArtoriaRen commented Nov 21, 2018

I am on Ubuntu 18.04 and encountered the same error :
runtime/cgo
exec: "gcc": executable file not found in $PATH

when I run "go test".

Solution: sudo apt install gcc

stevendanna added a commit to chef/scaffolding-go that referenced this issue Nov 27, 2018

Bump scaffolding-go, pulling in Go 1.11 (#9)
This unpins our version of core/scaffolding-go which in turn will pull
in the latest version of core/go.

All of A2 builds and passes tests with this change in place:

https://buildkite.com/chef/chef-a2-master-verify/builds/17409

In the past we had pinned our version of Go to avoid this bug:

golang/go#28065

However, rather than pinning, we should track down any places where
that is still an issue and either make sure those builds either have
gcc available or set GCO_ENABLED=0.

Signed-off-by: Steven Danna <steve@chef.io>
@thepudds

This comment has been minimized.

thepudds commented Nov 29, 2018

Hi @mvdan (and/or anyone else on this issue)

Good chance you already saw this, but it seems #26988 is now hopefully fixed in tip (where this issue #28065 was originally spun out from #26988).

I haven't personally seen anything that explicitly suggests that this issue #28065 might also be addressed, but it could be worth a quick try off of tip to see the situation here has improved.

@mvdan

This comment has been minimized.

Member

mvdan commented Nov 29, 2018

Thanks - I'll build tip on Alpine, and see if this bug is still present.

@mvdan

This comment has been minimized.

Member

mvdan commented Nov 29, 2018

Still appears to happen. New script:

docker run -i golang:1.11.2-alpine3.8 sh <<SCRIPT

cd /
apk add --no-cache --virtual .build-deps bash gcc musl-dev openssl git
go version
export GOROOT_BOOTSTRAP="$(go env GOROOT)"
git clone --depth=1 https://go.googlesource.com/go tip
cd tip/src
./make.bash
apk del .build-deps
/tip/bin/go version

cd /go
mkdir -p src/foo.com/bar
cd src/foo.com/bar

cat <<EOF >main.go
package main

import _ "net/http"

func main() {}
EOF

/tip/bin/go test

SCRIPT

Output:

[...]
go version devel +ba2e8f6 Thu Nov 29 18:18:51 2018 +0000 linux/amd64
# runtime/cgo
exec: "gcc": executable file not found in $PATH

@bcmills bcmills added the GoCommand label Nov 29, 2018

@bcmills bcmills changed the title from cmd/go: simple 'go test' on 1.11 requires gcc in GOPATH mode to cmd/go: 'go test' on alpine requires gcc in GOPATH mode Dec 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment