cmd/go: 'go test' fails to vet runtime/cgo when gcc not installed #42996
Comments
I wasn't able to reproduce this using the Dockerfile you gave. Could you please post:
In general, a standard library package needs to be recompiled if something in the global configuration that changes, for example, if you set |
Hi and thanks for your message!
|
Thanks for posting that repo. It doesn't look like the standard library is actually being recompiled with It looks like it's actually
I think we should probably close this, but cc @bcmills and @matloob in case they have other thoughts. |
If running |
@jayconrod yeah, you are right, @bcmills I totally agree with you. And similar thoughts have already occurred to other users: #28065 (comment), #28065 (comment) |
@georgysavva |
I agree with that, but I think it's only tangentially related. The OP listed I suspect that |
@jayconrod thanks for clarifying this! Thanks for looking into this, I hope you will find the reason. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I am running
go test
during the docker image build. My codebase consists of a single Go package and doesn't have any cgo code. Here is my Dockerfile:What did you expect to see?
I expected to see that
go test
successfully finishes after running my testsWhat did you see instead?
go test
failed with this message:I've noticed that if I add
go build -i -a std
before thego test ./...
command. It no longer needs to recompile:go test ./...
finishes successfully in that case.My question is what is the condition for
go test ./...
to recompile that standard library, because if I remove any of thosego build
flags:-i
or-a
the solution is no longer works. And why wouldgo test ./...
need to rebuild the standard library on a fresh Go installation at all?BTW, the situation is the same if I do
go vet ./...
instead ofgo test ./...
.I encountered this issue the first time with golang alpine image(golang:1.15.5-alpine3.12) because it doesn't have gcc installed. So this is pretty related to #28065. Maybe it's worth adding that command
go build -i -a std
to the official golang images to fix that kind of problem in user images that inherit them?Thanks!
The text was updated successfully, but these errors were encountered: