bazel: incompatible_use_cc_configure_from_rules_cc: Use cc_configure from @rules_cc
Flag: --incompatible_use_cc_configure_from_rules_cc
Introduced in: 1.2
Will be flipped: not anytime soon AFAIK
Description
We are moving cc_configure
, the logic that automatically configures C++ toolchain for the host machine, to @rules_cc
.
Migration
TODO
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 36 (20 by maintainers)
Links to this issue
Commits related to this issue
- Add NOOP __do_not_use_fail_with_incompatible_use_cc_configure_from_rules_cc Will be used when --incompatible_use_cc_configure_from_rules_cc is implemented. I'm adding the empty implementation so Baze... — committed to bazelbuild/bazel by hlopko 5 years ago
- Use bzl files from rules_cc repo in unit tests This is in preparation for incompatible_use_cc_configure_from_rules_cc (https://github.com/bazelbuild/bazel/issues/10134). This PR updates the rules_cc ... — committed to bazelbuild/bazel by hlopko 5 years ago
- Add --incompatible_use_cc_configure_from_rules_cc In this cl only add the flag. Installing the calls to __do_not_use_fail_with_incompatible_use_cc_configure_from_rules_cc will be done in a followup c... — committed to bazelbuild/bazel by hlopko 5 years ago
- Extract special BUILD file for //tools/cpp when present in the @bazel_tools Progress towards https://github.com/bazelbuild/bazel/issues/10134. RELNOTES: None. PiperOrigin-RevId: 280654359 — committed to bazelbuild/bazel by hlopko 5 years ago
- make `bazel build` work on aarch64/arm linux make ``` bazel build //tensorflow/tools/pip_package:build_pip_package ```` work again on aarch64 (e.g., EdgeTPU Dev board and Jetson boards) and arm (e.g,... — committed to freedomtan/tensorflow by freedomtan 4 years ago
- make `bazel build` work on aarch64/arm linux make ``` bazel build //tensorflow/tools/pip_package:build_pip_package ```` work again on aarch64 (e.g., EdgeTPU Dev board and Jetson boards) and arm (e.g,... — committed to freedomtan/tensorflow by freedomtan 4 years ago
- Downgrade `rules_go` for Apple Silicon compatibility (#6742) ## What is the goal of this PR? We downgrade `rules_go` from `0.35.0` to `0.34.0` (in `@vaticle_dependencies`), fixing an issue in C++ ... — committed to vaticle/typedb by alexjpwalker a year ago
Almost 2 years later, we are still coming here for instructions and there’s no instructions 🤦♂️
This ticket is still being linked from the error message and described as where to find “migration instructions”. I don’t see any of those, however.
For others arriving from the error message and looking to debug: I eventually found that adding
--toolchain_resolution_debug=@bazel_tools//tools/cpp:toolchain_type
let me figure out why no toolchains were matching, with very helpful info about why each match had failed. [Many thanks to whoever built that feature!]If others landing here find that to be the right next step, maybe we should add it to the error message. Maybe give a 👍🏻 if that’s you, so we can gauge usefulness?
Bazel docs here points to this issue for migration instructions but I don’t see any migration instructions here. Any idea when those will be posted?
I encountered this issue in https://github.com/bazelbuild/rules_docker/issues/1354 when attempting to cross compile a Go binary with CGO using rules_go on Linux for Mac.
FYI @jayconrod
If you came here because you trying to build go containers with rules_docker package, add os and arch explicitly to your go_image declaration
go_image( name = "base_image", embed = [":go_default_library"], visibility = ["//visibility:public"], goos = "linux", goarch = "amd64", )
Then you should delete old cache and rebuild
For anyone running into this issue on an Apple Silicon machine. Here is how I managed to solve it.
WORKSPACE
BUILD
file examplePer the current 4.2.1 docs and all of the discussions upthread, this flag is not flipped by default
Quoting from above:
I suggest confirming (perhaps by running with
--announce_rc
) that you have not flipped--incompatible_use_cc_configure_from_rules_cc=true
or--all_incompatible_changes
accidentally.If the error message you are seeing is “Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file?” then the key word there is Maybe.
Once you can confirm that you have not manually flipped this flag, then you can rest assured that your problem lies elsewhere ("No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type."), and has nothing to do with this issue #10134.
To the maintainer: perhaps this error message text is doing more harm than good, and should be removed: https://github.com/bazelbuild/bazel/blob/545befb13a64468377e3792a8f56c67cac245fa1/src/main/java/com/google/devtools/build/lib/skyframe/ToolchainResolutionFunction.java#L586-L589
If you come to this issue because of trying to build a docker image for language that doesn’t have platform specific builds from a non Linux machine (IE java, python, etc) you should add
build --@io_bazel_rules_docker//transitions:enable=false
to your bazelrc to work around this.@abhillman I believe this is what you’re running into.
I think the problem is that users have broken their C++ compiler (such that bazel can’t find it), and in that case they receive an error message with a hyperlink to this issue, so they assume this is where to find their salvation. It’s most likely just a red herring, though.
This helped solve the issue with go. But now it has spawned another issue with
No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type.