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: 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. 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. So, after adding the following flags to my go_binary, it started running correctly. |
|
Wonder if this is also fixed by #4009 |
|
I believe I'm also running into this issue while trying to set up llvm with a custom sysroot. I'm finding that cgo builds (in my case a build with the race detector which seems to turn cgo on by default) in my case trigger linker errors that look like this:
After diving in fairly deep, I found that
The above command fails because it can't actually find the sysroot. |
|
So after even more digging, I've found that it seems like this string ends up embedded in the race detector somewhere. Strings on one of the race detector standard library .a files comes up with this:
I only seem to have issues building programs with the race detector turned on. |
|
Ah right, I had missed the comments before about the ordering of flags in |
|
I have a patch that seems to be working for my case at least and opened a PR. I don't really know if this is the right solution but at least a problem here appears to be that #4009 was only a partial fix and only handled cases for compile operations but not link operations. Unfortunately because of how go tool link works I couldn't get the exact method working and had to write a sort of hacky script-based solution instead. |
|
Here's the upstream issue: golang/go#69954 I'll try to get to a test this week. |
|
@voxeljorge, I'm facing a similar issue: In my case I doubt it's a sysroot issue. I'm trying to make the "hermetic" llvm toolchain work under NixOS. Do you have any idea/tool to inspect better what's wrong? |
|
Hard to say, the issue I had really wasn't with relocation it was just that the linker was getting the wrong flags because all the flags were reported as unsupported. The simplest thing you could try is just adding -extldflags -v or something like that to make the linker more verbose. I wouldn't be able to tell you if your command is correct though, that would probably require a bit more spelunking than I have done. |
|
Fixed, I missed a |
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 linkprobes the linker (inlinkerFlagSupported) to determine if e.g.-no-pieshould 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:sysrootarg is passed twice, once from --extld flags and once from the go_ldflags attribute in the cgo object so the second--sysrootwins. 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 linkassumes 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
linkerFlagSupportedand none of them are correctly detecting flag support.The text was updated successfully, but these errors were encountered: