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)

Commits related to this issue

Most upvoted comments

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

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# Go (necessary to avoid issue described in this thread)

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "16e9fca53ed6bd4ff4ad76facc9b7b651a89db1689a2877d6fd7b82aa824e366",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.34.0/rules_go-v0.34.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.34.0/rules_go-v0.34.0.zip",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")

go_rules_dependencies()

go_register_toolchains(version = "1.18.3")

# Docker (setup as described in rules_docker repo example)

http_archive(
    name = "io_bazel_rules_docker",
    sha256 = "b1e80761a8a8243d03ebca8845e9cc1ba6c82ce7c5179ce2b295cd36f7e394bf",
    urls = ["https://github.com/bazelbuild/rules_docker/releases/download/v0.25.0/rules_docker-v0.25.0.tar.gz"],
)

load(
    "@io_bazel_rules_docker//repositories:repositories.bzl",
    container_repositories = "repositories",
)
container_repositories()

load("@io_bazel_rules_docker//repositories:deps.bzl", container_deps = "deps")

container_deps()

load("@io_bazel_rules_docker//container:container.bzl", "container_pull")

container_pull(
    name = "alpine_linux_arm64",
    digest = "sha256:9b2a28eb47540823042a2ba401386845089bb7b62a9637d55816132c4c3c36eb",
    registry = "index.docker.io",
    repository = "library/alpine",
    # tag field is ignored since digest is set
    tag = "latest",
)

BUILD file example

load("@io_bazel_rules_docker//container:container.bzl", "container_image")

container_image(
    name = "basic_alpine",
    base = "@alpine_linux_arm64//image",
    cmd = ["Hello World!"],
    entrypoint = ["echo"],
)

Per the current 4.2.1 docs and all of the discussions upthread, this flag is not flipped by default

Quoting from above:

This flag and this issue doesn’t have the labels required, therefore it won’t be flipped, and you can ignore it. I’d advice not to flip flags that don’t have the right Github labels set, you’ll only discover bugs and you’ll be met with no support from owners.

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.