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
During the build, it had to compile a Go binary for macOS (i.e., some tool to eventually run on the host platform). This ended up failing, because it had to run a GoToolchainBinaryBuild action. This action ended up getting run on the Linux workers, because it was the first platform in the list. There it failed with error:
/bin/bash: line 1: external/go_sdk/bin/go: cannot execute binary file: Exec format error
What did you expect to see?
That it ran the action on my local system.
What did you see instead?
That it attempted to run a copy of Go for macOS on the Linux workers.
I think that the root cause is that the go_tool_binary rule has absolutely no logic in place to ensure that an execution platform is used that matches up with the copy of the Go SDK. I tried to work around this by adding:
go_tool_binary() is completely oblivious of toolchains. The reason being
that Go toolchains actually depend on their output. Adding a toolchain
dependency would thus add a cyclic dependency. This is problematic,
because it means that the actions with mnemonic GoToolchainBinaryBuild
end up getting scheduled on arbitrary workers.
Address this by adding exec_compatible_with to the locations where
go_tool_binary() is instantiated, namely the auto-generated BUILD files
that are part of Go SDKs.
Fixes: bazel-contrib#3942
go_tool_binary() is completely oblivious of toolchains. The reason being
that Go toolchains actually depend on their output. Adding a toolchain
dependency would thus add a cyclic dependency. This is problematic,
because it means that the actions with mnemonic GoToolchainBinaryBuild
end up getting scheduled on arbitrary workers.
Address this by adding exec_compatible_with to the locations where
go_tool_binary() is instantiated, namely the auto-generated BUILD files
that are part of Go SDKs.
Fixes: #3942
What version of rules_go are you using?
0.47.1
What version of gazelle are you using?
n/a
What version of Bazel are you using?
7.0.2
Does this issue reproduce with the latest releases of all the above?
Yes.
What operating system and processor architecture are you using?
Remote execution cluster that has Linux x86_64 workers, in combination with a macOS client.
Any other potentially useful information about your toolchain?
n/a
What did you do?
I ran a Bazel build with the following flag set:
During the build, it had to compile a Go binary for macOS (i.e., some tool to eventually run on the host platform). This ended up failing, because it had to run a GoToolchainBinaryBuild action. This action ended up getting run on the Linux workers, because it was the first platform in the list. There it failed with error:
What did you expect to see?
That it ran the action on my local system.
What did you see instead?
That it attempted to run a copy of Go for macOS on the Linux workers.
I think that the root cause is that the
go_tool_binary
rule has absolutely no logic in place to ensure that an execution platform is used that matches up with the copy of the Go SDK. I tried to work around this by adding:But this fails due to a cyclic dependency:
The text was updated successfully, but these errors were encountered: