-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: 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: |
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. |
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.go
appears unchangedWhat operating system and processor architecture are you using (
go env
)?go env
OutputWhat 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 bazel-contrib/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.a
generated it contains apreferlinkext
entry. 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.go
The text was updated successfully, but these errors were encountered: