sluongng
commented
4 months ago FWIW, I can reproduce this with local execution as well, so this is not an RBE-related bug.
Open sluongng opened 4 months ago
sluongng
commented
4 months ago FWIW, I can reproduce this with local execution as well, so this is not an RBE-related bug.
motiejus
commented
4 months ago There isn't much we can do but report this upstream somewhere. So I will offer some guidance on what to do next and close this issue.
Please create a small test case case: a Go file and a specific zig cc command. Then file an issue to Zig or Go.
motiejus
commented
4 months ago Also, feel free to add the link to the task to this issue, so whoever is following have a trail. I will subscribe to whatever you register and keep an eye on.
sluongng
commented
4 months ago I think closing this would delegate the burden of troubleshooting to the user of the toolchain. But users may not have the skill/knowledge needed to properly create a reproduce.
For example: event though Zig toolchain is being used, in the action above, all I could see is
CC=/usr/local/bin/clangIt's unclear to me, a user, how to map that and the PATH=...:external/zig_sdk/tools/x86_64-linux-musl:... to a zig cc call 🤔
Furthermore, I think this toolchain repo should consider upgrading rules_go dependency + go_sdk to verify the reported issue using the existing test suite and avoid regression. So if breakage is found in that process, the toolchain maintainer should investigate and potentially fix this issue instead of closing it prematurely.
eko
commented
4 months ago Hi @sluongng, have you come to any solution please? I have the same issue after upgrading to Go 1.22
sluongng
commented
4 months ago We are weighing our options. Most likely we gonna stop using x86_64-linux-musl and/or hermetic_cc_toolchain entirely until the problem is fixed, or a better musl toolchain becomes available (such as https://github.com/bazel-contrib/musl-toolchain).
I am testing out https://github.com/bazel-contrib/toolchains_llvm/ with a custom sysroot as an alternative solution. But our problem is rather narrow and unique so folks will have to decide for themselves.
motiejus
commented
4 months ago I think closing this would delegate the burden of troubleshooting to the user of the toolchain.
Sorry about this, you were right. Reopening and will pin for higher visibility.
motiejus
commented
4 months ago Afaik if things are like they were a year ago Uber may have this problem too, since it uses musl for some targets.
@linzhp have you upgraded to 1.22 yet?
linzhp
commented
4 months ago We are on 1.22.1, but we are using @zig_sdk//toolchain:linux_amd64_gnu.2.19 and @zig_sdk//toolchain:linux_arm64_gnu.2.28 by default as you configured before. It's working.
There is only one shell script using musl to compile a Cgo target, and it did fail with the same error, but I guess no one is calling that shell script...
Example failure here https://app.buildbuddy.io/invocation/abd101b0-f5e3-4c5a-83ad-a459949a2905 with the remotely executed action here https://app.buildbuddy.io/invocation/abd101b0-f5e3-4c5a-83ad-a459949a2905?actionDigest=2141d6f2153f2060aef65156f6f74d66f2737bf6a25a818bb3e2419fb47c01b1%2F261&executeResponseDigest=77fe59ae3016c296887efe46b0b4d5c782385a865a92dc511672fd971ebf8947%2F127#action
Error message
On the surface, this looks like an incompatibility between Go 1.22 and
@zig_sdk//toolchain:linux_amd64_musllike reported in https://github.com/golang/go/issues/44695Additional info: