-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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/link: linker fails on linux/amd64 when gcc's annobin plugin is used #58620
Comments
Thanks for the report. I don't have a copy of the annobin plugin on my system, and it does not seem to be especially easy to build from source. Something seems fishy with your stack trace however -- the Go linker is trying to read host objects, which it only does in internal linking mode. The program that you are building uses CGO, however, and normally we use the external linker for CGO programs. Is there anything special you are doing to force internal linking? Thanks. |
@golang/compiler |
Whoops, on closer inspection it looks like there isn't any CGO use in the application itself, just in the various Go libraries (e.g. os/user, net) being linked in. FYI, you should be able to work around this issue by adding "ldflags=linkmode=external" to your "go build" invocation. |
You can easily reproduce this in the fedora:rawhide container. Fedora have annobin plugin built for its gcc and it is installed by default. For bit of context both issues discovery lays in the default C flags that Fedora uses. I haven't been able to easily reduce the reproducer for both. I was able to only reproduce it in the build of the loki's logcli. So I think that the size of the binary objects might be a factor or some (Go's?) compiler heuristics. Forcing the external linker is the workaround for both of the issues, I can confirm that. Thank you for a quick reply. |
Change https://go.dev/cl/470298 mentions this issue: |
Change https://go.dev/cl/470835 mentions this issue: |
This reverts CL 470298. Reason for revert: causes issues with Google internal testing. Updates #58619. Updates #58620. Change-Id: Ic6601820ba8758ef96b71e32d9ffc549c36d5c98 Reviewed-on: https://go-review.googlesource.com/c/go/+/470835 Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change https://go.dev/cl/471055 mentions this issue: |
Change https://go.dev/cl/475375 mentions this issue: |
This patch changes the Go command to examine the set of compiler flags feeding into the C compiler when packages that use cgo are built. If any of a specific set of strange/dangerous flags are in use, then the Go command generates a token file ("preferlinkext") and embeds it into the compiled package's archive. When the Go linker reads the archives of the packages feeding into the link and detects a "preferlinkext" token, it will then use external linking for the program by default (although this default can be overridden with an explicit "-linkmode" flag). The intent here is to avoid having to teach the Go linker's host object reader to grok/understand the various odd symbols/sections/types that can result from boutique flag use, but rather to just boot the objects in question over to the C linker instead. Updates #58619. Updates #58620. Updates #58848. Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa Reviewed-on: https://go-review.googlesource.com/c/go/+/475375 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
OK, this issue should now be resolved by CL 475375, just submitted this morning. Thanks. |
Change https://go.dev/cl/476576 mentions this issue: |
Change https://go.dev/cl/476577 mentions this issue: |
… strange cgo flags seen This patch changes the Go command to examine the set of compiler flags feeding into the C compiler when packages that use cgo are built. If any of a specific set of strange/dangerous flags are in use, then the Go command generates a token file ("preferlinkext") and embeds it into the compiled package's archive. When the Go linker reads the archives of the packages feeding into the link and detects a "preferlinkext" token, it will then use external linking for the program by default (although this default can be overridden with an explicit "-linkmode" flag). The intent here is to avoid having to teach the Go linker's host object reader to grok/understand the various odd symbols/sections/types that can result from boutique flag use, but rather to just boot the objects in question over to the C linker instead. Fixes #59051. Updates #58619. Updates #58620. Updates #58848. Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa Reviewed-on: https://go-review.googlesource.com/c/go/+/475375 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 035db07) Reviewed-on: https://go-review.googlesource.com/c/go/+/476577
… strange cgo flags seen This patch changes the Go command to examine the set of compiler flags feeding into the C compiler when packages that use cgo are built. If any of a specific set of strange/dangerous flags are in use, then the Go command generates a token file ("preferlinkext") and embeds it into the compiled package's archive. When the Go linker reads the archives of the packages feeding into the link and detects a "preferlinkext" token, it will then use external linking for the program by default (although this default can be overridden with an explicit "-linkmode" flag). The intent here is to avoid having to teach the Go linker's host object reader to grok/understand the various odd symbols/sections/types that can result from boutique flag use, but rather to just boot the objects in question over to the C linker instead. Fixes #59050. Updates #58619. Updates #58620. Updates #58848. Change-Id: I56382dd305de8dac3841a7a7e664277826061eaa Reviewed-on: https://go-review.googlesource.com/c/go/+/475375 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 035db07) Reviewed-on: https://go-review.googlesource.com/c/go/+/476576
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes, seems to be reproducible at least as far back as go1.18
What operating system and processor architecture are you using (
go env
)?go env
OutputThis is with gcc-13.0.1, binutils-2.40 and glibc-2.37
What did you do?
git clone https://github.com/grafana/loki
cd loki
export CGO_CFLAGS="-fplugin=gcc-annobin"
go build -o logcli ./cmd/logcli
What did you expect to see?
Build finishing successfully or more clear error message being displayed.
What did you see instead?
The text was updated successfully, but these errors were encountered: