-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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 lto options are used #58619
Comments
@golang/compiler |
Similar to #58620, we're doing CGO internal linking (due to use of CGO in "net" and related packages), and the linker's host object loader is getting confused by the non-standard objects. |
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Than McIntosh <[email protected]> Reviewed-by: Than McIntosh <[email protected]> Reviewed-by: Cherry Mui <[email protected]>
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 <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Run-TryBot: Than McIntosh <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
This issue should now be resolved by CL 475375, submitted this morning. Thanks. |
@gopherbot please open backport issues |
Backport issue(s) opened: #59050 (for 1.19), #59051 (for 1.20). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
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 <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Run-TryBot: Than McIntosh <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (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 <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Run-TryBot: Than McIntosh <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (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='-O2 -flto=auto -ffat-lto-objects'
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: