Description
What happened?
The immediate symptom is that upgrading to Bazel 8.x and generating sources via js_run_binary
consumed by a Windows binary causes the following build error:
external/rules_cc+/cc/BUILD:103:19: in cc_toolchain_alias rule @@rules_cc+//cc:current_cc_toolchain:
Traceback (most recent call last):
File "/virtual_builtins_bzl/common/cc/cc_toolchain_alias.bzl", line 26, column 48, in _impl
File "/virtual_builtins_bzl/common/cc/cc_helper.bzl", line 163, column 13, in _find_cpp_toolchain
Error in fail: Unable to find a CC toolchain using toolchain resolution. Target: @@rules_cc+//cc:current_cc_toolchain, Platform: @@platforms//host:host, Exec platform: @@bazel_tools//tools:host_platform
The cause of this is that js_run_binary
by default sets use_execroot_entry_point
which hoists runfiles of the js_binary to execroot to better mimic how JS tools are run. However, run_binary
forces a cfg = "exec"
transition on tool
. But, the same is not done for these runfile srcs which I believe by default use the target platform.
Bazel 8 is forcing CC toolchain resolution for reasons unknown to me, which may suggest another bug about why a CC toolchain is required at all.
Version
Development (host) and target OS/architectures: Linux, targeting Windows x86_64
Output of bazel --version
: 8.1.1
Version of the Aspect rules, or other relevant rules from your
WORKSPACE
or MODULE.bazel
file:
Language(s) and/or frameworks involved: js_run_binary
How to reproduce
Quick demo of how to reproduce this:
https://github.com/sallustfire/rules_js/tree/js-run-binary-platform-runfiles
Any other information?
This is loosely related: #2073
The most naive change here would be to force a transition on the hoisted runfiles.