Skip to content
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

x/vgo: Tests on pristine golang:alpine container require gcc #25204

Closed
computermouth opened this issue May 1, 2018 · 2 comments

Comments

@computermouth
Copy link

commented May 1, 2018

Please answer these questions before submitting your issue. Thanks!

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

go version go1.10.1 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
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"
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-build112142147=/tmp/go-build -gno-record-gcc-switches"
VGOMODROOT=""

What did you do?

vgo test -ldflags="-s -w" -v in golang:alpine Docker container

If possible, provide a recipe for reproducing the error.

main.go

package main

import "fmt"

func retFour() int {
	return 4
}

func main() {
	fmt.Printf("hello %d\n", retFour())
}

main_test.go

package main

import (
	"testing"
)

func TestFour(t *testing.T) {
	if retFour() != 4 {
		t.Errorf("not four!")
	}
}

go.mod

module github.com/some/prgm

require github.com/aws/aws-sdk-go v1.13.39

Dockerfile

FROM golang:alpine
RUN apk --no-cache add git
COPY go.mod       /build/go.mod
COPY main.go      /build/main.go
COPY main_test.go /build/main_test.go
WORKDIR /build
#RUN go get github.com/aws/aws-sdk-go/aws
#RUN go get github.com/aws/aws-sdk-go/aws/session
#RUN go get github.com/aws/aws-sdk-go/service/s3/s3manager
#RUN go test -ldflags="-s -w" -v
RUN go get -u golang.org/x/vgo
RUN vgo test -ldflags="-s -w" -v
RUN CGO_ENABLED=0 GOOS=linux vgo build -a -ldflags '-s -w -extldflags "-static"' .

What did you expect to see?

Building with: docker build .
A successful test and build. (Uncomment the four lines above, and comment out vgo test)

Step 8/9 : RUN vgo test -ldflags="-s -w" -v
 ---> Running in c46713f27370
vgo: finding github.com/aws/aws-sdk-go v1.13.39
vgo: finding github.com/jmespath/go-jmespath v0.0.0-20160202185014-0b12d6b521d8
vgo: finding github.com/go-ini/ini v1.25.4
vgo: downloading github.com/aws/aws-sdk-go v1.13.39
vgo: downloading github.com/go-ini/ini v1.25.4
vgo: downloading github.com/jmespath/go-jmespath v0.0.0-20160202185014-0b12d6b521d8
=== RUN   TestFour
--- PASS: TestFour (0.00s)
PASS
ok  	github.com/some/prgm	0.006s

What did you see instead?

A hard dependency on gcc, causing a failure of the tests.

Step 8/9 : RUN vgo test -ldflags="-s -w" -v
 ---> Running in c46713f27370
vgo: finding github.com/aws/aws-sdk-go v1.13.39
vgo: finding github.com/jmespath/go-jmespath v0.0.0-20160202185014-0b12d6b521d8
vgo: finding github.com/go-ini/ini v1.25.4
vgo: downloading github.com/aws/aws-sdk-go v1.13.39
vgo: downloading github.com/go-ini/ini v1.25.4
vgo: downloading github.com/jmespath/go-jmespath v0.0.0-20160202185014-0b12d6b521d8
# runtime/cgo
exec: "gcc": executable file not found in $PATH

If go is used for the tests rather than vgo, it works just fine.

@gopherbot gopherbot added this to the vgo milestone May 1, 2018

@computermouth computermouth changed the title x/vgo: Tests on pristine golang:alpine container requre gcc x/vgo: Tests on pristine golang:alpine container require gcc May 1, 2018

@computermouth

This comment has been minimized.

Copy link
Author

commented May 1, 2018

The problem is resolved by changing the test command to:
CGO_ENABLED=0 vgo test -ldflags="-s -w" -v

But in any case, the behaviour is different between the two binaries.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2018

It's not a hard dependency on gcc. It's rebuilding the runtime/cgo instead of using the go distribution's prebuilt runtime/cgo.a. This is basically working as intended - vgo is its own build system and should not assume it's in sync with whatever go distribution you are using. The workaround is to have an appropriate C compiler in the container or disable cgo, sorry.

Once vgo is part of the main go command this will no longer happen.

@rsc rsc closed this Jun 6, 2018

@golang golang locked and limited conversation to collaborators Jun 6, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.