-
Notifications
You must be signed in to change notification settings - Fork 633
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
cgo: go link
detects all linker flags as unsupported when using custom cc toolchain
#3886
Comments
@ianlancetaylor, was the ordering of extldflags before the LDFLAGS from cgo directives in func linkerFlagSupported(arch *sys.Arch, linker, altLinker, flag string) bool {
...
moreFlags := trimLinkerArgv(append(flagExtldflags, ldflag...)) |
I can't answer that question, but ideally we wouldn't include any absolute paths into the outputs of compilation. Maybe we could use a symlink instead of converting the sysroot to an absolute path? That said, if flipping the order of flags is a simple way to fix this and no tests break, I'm happy to accept that change. |
I don't understand what is creating the absolute path. The code you mention in cmd/cgo only applies to Go file names, not to options like |
Ah ya, misread that. Thanks. So this is actually happening in rules_go. The flags are getting absolute here: rules_go/go/tools/builders/stdlib.go Lines 161 to 165 in aeb83e8
So we have a --sysroot from a custom cc toolchain. When building the stdlib with
|
I encountered the same issue. We use a custom cc toolchain, the binaries built success but cannot run.
According @mikedanese , I try to remove the codes of absEnv as mentioned above , but not works, the issue persists. rules_go/go/tools/builders/stdlib.go Lines 161 to 165 in aeb83e8
I found that when rule_go link the binary, it doesn't fetch clink flags through clinkopts; instead, it reads gc_linkopts and puts the flags after -extldflags into _extract_extldflags. rules_go/go/private/actions/link.bzl Lines 64 to 106 in c0ef535
rules_go/go/private/actions/link.bzl Lines 230 to 240 in c0ef535
So, after adding the following flags to my go_binary, it started running correctly.
|
What version of rules_go are you using?
master sync'd to latest
What version of Bazel are you using?
Does this issue reproduce with the latest releases of all the above?
What operating system and processor architecture are you using?
Linux
What did you see instead?
I have a custom cc toolchain based on LLVM. This toolchain sets a sysroot link option, e.g.
--sysroot=external/sysroot-linux-x86_64-gnu7-llvm-1
.When a cgo library is generated, the cgo tool converts this LD_FLAG value into an absolute path here: https://cs.opensource.google/go/go/+/master:src/cmd/cgo/main.go;l=353-357;drc=bdccd923e914ab61d77a8f23a3329cf1d5aaa7c1. For example, my sysroot ldflag might be converted to
/home/mike.danese/.cache/bazel/_bazel_mike.danese/71e455921cc87b7db5489570176e2cff/sandbox/linux-sandbox/400/execroot/universe/external/sysroot-linux-x86_64-gnu7-llvm-16
. These LD_FLAGs get backed into the object.Now when it's time to link,
go tool link
probes the linker (inlinkerFlagSupported
) to determine if e.g.-no-pie
should be configured: https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/lib.go;l=1833-1834;drc=2ab9218c86ed625362df5060f64fcd59398a76f3. It does this by compiling a trivial program. To construct the compile command, the ldflags from the cgo object are appended to the extdld flags: https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/lib.go;l=2079-2080;drc=2ab9218c86ed625362df5060f64fcd59398a76f3. This results in a command like this:sysroot
arg is passed twice, once from --extld flags and once from the go_ldflags attribute in the cgo object so the second--sysroot
wins. This is a problem because the second sysroot references a path in the no longer existant execution sandbox where the cgo object was compiled. Thus, the probe fails with a nonsensical error:This error is swallowed silently, and
go link
assumes that the linker flag is unsupported. In the case of-no-pie
, this causes rules_go to attempt to link PIE cgo objects into go binaries without relro (e.g. in normal exe buildmode on linux). This causes hard to debug runtime errors such as:There are ~10 other calls to
linkerFlagSupported
and none of them are correctly detecting flag support.The text was updated successfully, but these errors were encountered: