Closed bearsh closed 1 month ago
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
just to make it clear, the library works in the end (and the exit code from the build process is 0)...
so this might not be a real bug but rather a annoyance in the output
@golang/compiler
Just to be clear, this only shows up with -x
? In triage, we note that we regard cmd/cgo-invoked external linkers as having errors as OK. cmd/cgo will actually invoke external linkers and look at the output to try and understand what certain referenced symbols actually are. It's expected that some of these invocations will fail.
But simultaneously, it's a bit surprising these particular errors are ending up in the output at all. Can you share the full output of go build -a -x
for your program?
Just to be clear, this only shows up with -x?
well yes but a subsequent plain go build
will also show the errors. a fresh go build -a
will hide it again.
I see where this output is coming from. In cmd/go/internal/work, the function (*Builder).gccld
(https://go.googlesource.com/go/+/refs/heads/master/src/cmd/go/internal/work/exec.go#2246) runs the C linker. That function for some reason prints the C linker output when invoked with the go build
-x
or -n
options. There is a comment in the code:
// Note that failure is an expected outcome here, so we report output only
// in debug mode and don't report the error.
This behavior appears to date back to https://go.dev/cl/413460. Before that CL, we always printed the errors, even though things were actually OK. See #52863. Now we hide the errors, but we print them when using -x
. I do not remember why I did things that way, because it clearly introduces confusion. Especially since we don't seem to print the command that causes those errors, though we should.
So in general the build is working fine. This is a cmd/go issue. CC @matloob @samthanawalla though maybe I should try to work on it since I seem to have introduced it.
@ianlancetaylor We'd definitely appreciate the help but we could fix it too: though we'd like to figure out that the behavior should be. It seems like the two options are that we hide the errors, or that we print the command causing the error along with the error?
I'm not sure what the best choice is. Another option is to display the command but not the output. It's a confusing case because it's fine if the link fails, but that is not obvious to the person reading the output. Maybe we could add a comment? There is precedent in the # internal
comment we print on the pack command.
Hm, I like the idea of adding a comment. I suppose we could start with that?
Change https://go.dev/cl/615916 mentions this issue: cmd/go: don't print dynimport link error messages
Go version
go version go1.22.5 linux/amd64
Output of
go env
in your module/workspace:What did you do?
I maintain go binding to hidapi. After restructuring the project I discovered linker errors when building with the
-x
flag.steps to reproduce:
then call go build, make sure CGO is enabled. this outputs a linker error:
What did you see happen?
What did you expect to see?
no errors