You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What happened: linking a Cgo library into a Go binary produces a warning about incorrect use of DT_TEXTREL in a PIE target.
What I expected: no warnings, because consistent link strategies are used for intermediate and final results.
A Go package that uses cgo, compiled as a library in debug mode, will normally produce a .gopclntab that requires relocations. When using the standard Go rules with a system C toolchain on various flavors of Ubuntu, cgo=True libraries are built such that .gopclntab and other relocated read-only sections are prefixed with .data.relro. It appears that some interaction between the Aspect GCC toolchain and the Go rules is leading to a situation where intermediate .o files for Go builds are using internal linkage, while the final link step is using GNU ld as an external linker.
That conflict causes warnings and has in the past been a sign of binaries with executable data sections that need to be specially handled by the system loader. Notably, various musl-based systems are not able to correctly load such binaries.
One possible cause here is that the PIE-by-default nature of the GCC toolchain is not correctly detected by the Go rules.
Development (host) and target OS/architectures:
Host is Ubuntu 22.04.3 LTS, uname -srv Linux 6.2.0-1018-gcp #20~22.04.1-Ubuntu SMP Mon Oct 23 12:29:43 UTC 2023
Target is Linux x86-64, with similar kernel revisions
Output of bazel --version: bazel 6.4.0
Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file: @io_bazel_rules_go = v0.43.0, Go toolchain = 1.20.2, Aspect GCC toolchain = 0.4.2
What happened?
What happened: linking a Cgo library into a Go binary produces a warning about incorrect use of DT_TEXTREL in a PIE target.
What I expected: no warnings, because consistent link strategies are used for intermediate and final results.
A Go package that uses cgo, compiled as a library in debug mode, will normally produce a .gopclntab that requires relocations. When using the standard Go rules with a system C toolchain on various flavors of Ubuntu,
cgo=True
libraries are built such that.gopclntab
and other relocated read-only sections are prefixed with.data.relro
. It appears that some interaction between the Aspect GCC toolchain and the Go rules is leading to a situation where intermediate.o
files for Go builds are using internal linkage, while the final link step is usingGNU ld
as an external linker.That conflict causes warnings and has in the past been a sign of binaries with executable data sections that need to be specially handled by the system loader. Notably, various musl-based systems are not able to correctly load such binaries.
One possible cause here is that the PIE-by-default nature of the GCC toolchain is not correctly detected by the Go rules.
See golang/go issue 10914, 17847, and 59866 for related discussions.
Version
Development (host) and target OS/architectures:
Host is Ubuntu 22.04.3 LTS,
uname -srv
Linux 6.2.0-1018-gcp #20~22.04.1-Ubuntu SMP Mon Oct 23 12:29:43 UTC 2023Target is Linux x86-64, with similar kernel revisions
Output of
bazel --version
: bazel 6.4.0Version of the Aspect rules, or other relevant rules from your
WORKSPACE
orMODULE.bazel
file:@io_bazel_rules_go
= v0.43.0, Go toolchain = 1.20.2, Aspect GCC toolchain = 0.4.2Complete repo available at https://github.com/rbosetti/aspect-repro
Language(s) and/or frameworks involved: Go, C
How to reproduce
Any other information?
Output from the repro step.
The text was updated successfully, but these errors were encountered: