Skip to content
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

go_tool_binary / GoToolchainBinaryBuild actions don't always run on the correct platform #3942

Closed
EdSchouten opened this issue May 15, 2024 · 0 comments · Fixed by #3943
Closed

Comments

@EdSchouten
Copy link
Contributor

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:

--extra_execution_platforms=//some/linux/platform,//some/macos/platform

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:

toolchains = ["@io_bazel_rules_go//go:toolchain"],

But this fails due to a cyclic dependency:

    ...
    @@go_sdk//:go_darwin_amd64-impl (c55e8f4de7cab132a0f1e0fde73344500194ac1db34f6fc75005ccf41302d350)
.-> @@go_sdk//:builder_reset (ca07856a6315d9ce49d448350dcbda8b02b33c99dce524cc4378883f88bd1701)
|   @@go_sdk//:builder (ca07856a6315d9ce49d448350dcbda8b02b33c99dce524cc4378883f88bd1701)
|   @@go_sdk//:go_darwin_amd64-impl (ca07856a6315d9ce49d448350dcbda8b02b33c99dce524cc4378883f88bd1701)
`-- @@go_sdk//:builder_reset (ca07856a6315d9ce49d448350dcbda8b02b33c99dce524cc4378883f88bd1701)
EdSchouten added a commit to EdSchouten/rules_go that referenced this issue May 15, 2024
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
fmeum pushed a commit that referenced this issue May 15, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant