Open illicitonion opened 2 weeks ago
@pzembrod @oquenchil
Does this also happen to Bazel@HEAD?
@fmeum Are you looking into a fix?
I am
@meteorcloudy With last_green
, I get a different failure:
ERROR: Error computing the main repository mapping: at /private/var/tmp/_bazel_fmeum/1be3cb90b5e931599cbed59281fc8ffa/external/bazel_tools/tools/cpp/cc_configure.bzl:18:6: Label '@@rules_cc//cc/toolchains:toolchain_config_utils.bzl' is invalid because 'cc/toolchains' is not a package; perhaps you meant to put the colon here: '@@rules_cc//cc:toolchains/toolchain_config_utils.bzl'?
This is happening because @rust_darwin_aarch64__aarch64-apple-darwin__stable_tools//:rust_toolchain
(on my MacBook) contributes a LinkerInput
(which was previously ignored since it only contains linkopts), but isn't visited by the aspect that accumulates the transitive dependencies for the topological sort as it doesn't advertise CcInfo
. You could argue it's not a regression, but surfaces a deeper issue that has been present all along. :-)
@oquenchil Did you factor in LinkerInputs
contributed by toolchains when you wrote cc_shared_library
? Do you happen to have an idea how they could be accommodated?
I am also seeing this issue on a pure (I think) C++ build. 7.4.0rc2 is OK, 7.4.0 has the issue.
@meteorcloudy We'll look for a fix for Bazel@HEAD and Bazel 8, but we should definitely revert this for 7.4.0. I sent https://github.com/bazelbuild/bazel/pull/24087.
Fabian I don't remember anything related to LinkerInputs in toolchains that I can give you as context. I think I didn't add anything specific since back then because when I wrote it toolchains didn't have objects of the LinkerInput class (or any C++ provider), not sure if that's not the case anymore.
The cc_shared_library aspect only propagated via the CcInfo provider. The actual linker inputs from the toolchains were added to actions but as as raw files, not wrapped in the LinkerInput class. Adding the raw toolchain files has always been done automatically behind the cc_common API without having to do it explicitly.
I can tell you though that Mai added an API for aspects propagated to toolchains back in July https://github.com/bazelbuild/bazel/commit/68ee1e4169c99645c803bda79eb3f1e198d8b055
Maybe that's relevant and it can help.
Description of the bug:
rules_rust CI picks up latest Bazel releases. Since 7.4.0 was released, our CI has been failing with:
See https://buildkite.com/bazel/rules-rust-rustlang/builds/12498#0192ba36-aa5a-49d7-af36-0c85e2c50257 for an example.
Repro by cloning https://github.com/bazelbuild/rules_rust at 113439296e4c264aa4ac7fe49f35eb52f0c95dcb and running:
USE_BAZEL_VERSION=7.4.0 bazel test test/cc_shared_library/...
7.3.2 passes cleanly.
Which category does this issue belong to?
C++ Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Clone https://github.com/bazelbuild/rules_rust at 113439296e4c264aa4ac7fe49f35eb52f0c95dcb and run:
USE_BAZEL_VERSION=7.4.0 bazel test test/cc_shared_library/...
Which operating system are you running Bazel on?
Any
What is the output of
bazel info release
?release 7.4.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
c1183081083d01cbd088c9fa352812a5f5d4408d
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
cc @fmeum