Go Toolchain Based On Target Configuration

[nathantchan]

Right now, the go_toolchain uses the host's configuration. This creates issues in cgo when the C code is compiled according to a target configuration that is different from the hosts. Will there be support for the go_toolchain using differing target configurations?

[jayconrod]

To answer your specific question, you can select the Go toolchain with --experimental_platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 (replacing the last part with your goos_goarch). If you specify --cpu on the command line, this will be inferred (at least, for the --cpu values we know about).

More broadly though, we don't support cross-compiling cgo yet. It's something we'd like to support in the future, but cross-compiling C/C++ with Bazel is difficult.

I'll close this as a duplicate of #1020, which is the main issue tracking cross-compilng cgo.

[brian-peloton]

I think this is a different problem than cross-compiling. Currently, from what I can tell, cgo always ends up using the "host" Bazel configuration's C/C++ toolchain, instead of the "target" one. This can sometimes mean selecting a different toolchain, potentially from a different CROSSTOOL, with different flags. The result doesn't always link correctly with target-configuration cc_library rules, even if they are the same --cpu. It also makes selecting a different compiler with --compiler impossible if you specify --host_crosstool_top, because when --host_crosstool_top is specified the host compiler is always the CROSSTOOL-specified default one; --compiler only affects the target compiler in that situation.

I work with @nathantchan, and we worked around this locally by switching back to pulling C/C++ information from ctx.fragments.cpp instead of go_toolchain. That correctly uses the target C/C++ toolchain for target-configuration rules.

It's possible this is a fundamental limitation of Bazel's toolchain support too, but it seems worth raising it here before filing a bug with Bazel itself.

[ianthehat]

It's the same problem, just a different symptom. We call anything where target != host cross compiling, and in this case you are causing that to be true, even though the target os and architecture are the same, because the crosstool is not.
The problem is that the stdlib rule is evaluated as part of the toolchain construction, and toolchain construction happens after a target->host configuration transition, so it always gets the host fragment.
I have talked to the bazel team about a way to fix it, but it's not going to arrive any time soon.
The only way to fix this right now is to move the stdlib dependancy from the toolchain up to the individual rules, which did not used to be possible, but that is what I am going to try next.