cmd/go: don't prefer external linking when using bazelbuild/rules_go #60865
Comments
The -fdebug-prefix-map= option is passed by bazelbuild/rules_go when building cgo code. This option impacts the generation of the debug symbols but has no effect on linking. Add it to the allow-list to not prefer external linking. Fixes: golang#60865
|
Change https://go.dev/cl/504335 mentions this issue: |
bcmills
added
GoCommand
Note that Since Bazel presumably knows whether it expects a C linker to be invoked, it should probably use one of those mechanisms explicitly to avoid making fragile assumptions about which flags do or do not trigger external linking by default. |
bcmills
added
the
NeedsInvestigation
mknyszek
changed the title
|
Allowing As @bcmills mentioned, explicitly passing |
My understanding is that the go command is looking at each input, cgo, msan, asan, the GOOS and GOARCH to resolve linkmode=auto (determineLinkMode) and then looks whether it can proceed (extNeeded). It seems that unconditionally passing flags to force internal linking, certain architectures and OSes will fail to link. It seems undesirable and close to impossible (bazel does not inspect the .o files) to resolve LinkAuto in rules_go. Why does this behavior change matter? I have orders of magnitude more confidence in Go doing the right thing than the less frequently updated random C toolchain. |
This sounds like you really want internal linking on certain condition. If this is a requirement for bazel, it still makes sense to make that explicitly. (This is not a requirement for the Go toolchain, at least not a hard requirement. So it an still change in the future.) You don't need to inspect object files. Basically, any (non-std) cgo, msan, or asan means external linking, as well as a small number of special GOOS/GOARCH combinations where internal linking is not supported/implemented. This is the default behavior for the linker. |
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Last-Rev: 4127df6 GitHub-Pull-Request: golang#60868
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Last-Rev: 4127df6 GitHub-Pull-Request: golang#60868
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. As a side effect, it also allows these flags to appear in #cgo directives in source code. We don't know of any cases where that is actually useful, but it appears to be harmless and simplifies the implementation of the internal linking change. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Last-Rev: 4127df6 GitHub-Pull-Request: golang#60868
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. As a side effect, it also allows these flags to appear in #cgo directives in source code. We don't know of any cases where that is actually useful, but it appears to be harmless and simplifies the implementation of the internal linking change. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Pull-Request: golang#60868
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. As a side effect, it also allows these flags to appear in #cgo directives in source code. We don't know of any cases where that is actually useful, but it appears to be harmless and simplifies the implementation of the internal linking change. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Pull-Request: golang#60868
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. As a side effect, it also allows these flags to appear in #cgo directives in source code. We don't know of any cases where that is actually useful, but it appears to be harmless and simplifies the implementation of the internal linking change. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Pull-Request: golang#60868
In CL 475375 the Go command started to generate the "preferlinkext" token file for "strange/dangerous" compiler flags. This serves as a hint to the Go linker whether to call the external linker or not. Permit compiler flags used by bazel and bazelbuild/rules_go during compilation of cgo code to not prefer external linking. This restores the behavior of previous versions of Go. As a side effect, it also allows these flags to appear in #cgo directives in source code. We don't know of any cases where that is actually useful, but it appears to be harmless and simplifies the implementation of the internal linking change. Fixes golang#60865 Change-Id: I176a6a2a2cf36293dd9aed24be928f98fa2fb6d9 GitHub-Pull-Request: golang#60868
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
src/cmd/go/internal/work/security.goappears unchangedWhat operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I am using bazel + rules_go to compile an application that requires cgo (e.g., uses os/user) and have upgraded from Go 1.19 to 1.20. The build set-up is described in bazelbuild/rules_go#3590.
What did you expect to see?
In Go 1.19 the Go linker is linking the final binary. I expected this to continue.
What did you see instead?
Go 1.20 is actually invoking the external linker.
Looking at the linker output I notice:
Inspecting the
os/user.agenerated it contains apreferlinkextentry. This seems to be the case because rules_go is passing-fdebug-prefix-map=...as CGO_CFLAGS. I would like to allow list this flag tosrc/cmd/go/internal/work/security.goThe text was updated successfully, but these errors were encountered: