GoStdlib, GoCompilePkg, etc. don't respect exec_compatible_with of the underlying C/C++ toolchain

What version of rules_go are you using?

v0.46.0

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?

It likely does.

What operating system and processor architecture are you using?

macOS Sonoma

Any other potentially useful information about your toolchain?

Bazel is configured to use a remote execution cluster that only provides Linux workers. The idea is that as much as possible should run on the remote cluster, but for certain actions Bazel should fall back to executing locally. So I'm providing something along the lines of:

--extra_execution_platforms=//myplatforms:linux,//myplatforms:macos

What did you do?

As part of my build, I need to compile a Go program for the host (i.e., macOS) that makes use of cgo.

What did you expect to see?

That this simply works out of the box. Namely, that it decides to run these actions locally, because only there I have a copy of Xcode that can be used to build software for macOS:

What did you see instead?

A failure along these lines, caused by it trying to run the action remotely:

# runtime/cgo
cgo: exec ./external/local_config_apple_cc/wrapped_clang: fork/exec ./external/local_config_apple_cc/wrapped_clang: exec format error
stdlib: error running subcommand GOARCH=amd64 \

I think that the issue is that rules_go resolves the Go and C/C++ toolchains independently, as opposed to declaring a single exec_group() that contains both these toolchains. This means that in the case of the Go toolchain it decides that cross compiling from Linux is the best strategy.

bazelbuild / rules_go