Error in fail: Compiling objc_library targets requires the Apple CC toolchain

[sgowroji]

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3319#018ab078-1251-4412-a17f-cc5e782ea20e

Platform : rules_swift (Current LTS using bzlmod on :darwin: (OpenJDK 11, Xcode))

Logs:

ERROR: /Users/buildkite/builds/bk-imacpro-18/bazel-downstream-projects/rules_swift/examples/apple/objc_interop/BUILD:13:13: in objc_library rule //examples/apple/objc_interop:PrintStream:
Traceback (most recent call last):
	File "/virtual_builtins_bzl/common/objc/objc_library.bzl", line 61, column 52, in _objc_library_impl
	File "/virtual_builtins_bzl/common/objc/semantics.bzl", line 54, column 13, in _check_toolchain_supports_objc_compile
Error in fail: Compiling objc_library targets requires the Apple CC toolchain which can be found here: https://github.com/bazelbuild/apple_support#toolchain-setup
(05:10:10) ERROR: /Users/buildkite/builds/bk-imacpro-18/bazel-downstream-projects/rules_swift/examples/apple/objc_interop/BUILD:13:13: Analysis of target '//examples/apple/objc_interop:PrintStream' failed
(05:10:10) ERROR: Analysis of target '//examples/apple/objc_interop:PrintStream' failed; build aborted
(05:10:10) ERROR: Build did NOT complete successfully

Steps:

git clone https://github.com/bazelbuild/rules_swift.git 
git reset 8c0904124f3b7fbeb08d7863b8b5949cbe359252 --hard
export USE_BAZEL_VERSION=81b4b91bc98acc404690cd833cd6a1a592f3ee17
bazel build --enable_bzlmod --platform_mappings=platform_mappings_bzlmod //examples/...

Culprit Found: 1be55d8add84c2d04c3353b7e481a7866a92eac7

Cc Greenteam @comius

[brentleyjones]

This requires a fix in Bazel, with a new rules_cc release. @meteorcloudy is working on that now.

[meteorcloudy]

Note that even with my fix, you'll have to make sure apple_support is defined before rules_cc, which is already true:

rules_swift/MODULE.bazel

Lines 10 to 11 in 8c09041

	bazel_dep(name = "apple_support", version = "1.9.0", repo_name = "build_bazel_apple_support")
	bazel_dep(name = "rules_cc", version = "0.0.2")

But this could be brittle, not sure if there is any way to actually filter out the non apple cc toolchains during toolchain resolution.

[brentleyjones]

But this could be brittle

You're telling me! Seems like a Bazel change is needed for that.

[meteorcloudy]

But I have no idea what else we could do from Bazel side, toolchain resolution has to follow an order, and it is currently a BFS order of all registrations from the root module.

[comius]

cc @katre

I believe there are some ideas, how to make order of registration matter less. It’s more of a toolchain resolution problem than bzlmod.

[katre]

The problem is that there are multiple matching cc toolchains, at least one from apple_support and another from rules_cc, and the wrong one is being used? Do we know which toolchains those are?

The best idea we've come up with so far would be to add a priority parameter to the existing register_toolchains function. However, it's hard to figure out how to define this so that rules_cc uses a lower priority than apple_support.

Instead of this, can the problematic cc_toolchain entries be removed from rules_cc?

[keith]

rules_cc is registering the builtin toolchain now bazelbuild/rules_cc@0097505, maybe it could just not do that until things move to rules_cc?

[meteorcloudy]

Yeah, sounds like we should remove the toolchain registration in rules_cc all together.

[comius]

Why not removing it from bazel_tools instead?

[comius]

I think that rules_cc and rules_java should do the toolchain registration themselves, and it shouldn't happen in @bazel_tools.

That is because then the rules_java, rules_cc repos can be updated independently of Bazel.

[fmeum]

Fully agree with @comius here, we have already moved all the Java toolchains into rules_java, we should do the same with rules_cc and then remove the registrations from bazel_tools.

In my opinion the missing piece is the equivalent of --java_runtime_version or --java_language_version for C++ toolchains: There needs to be some semantically meaningful way to distinguish between multiple registered toolchains. I just don't see how numeric priorities can work well in a heterogeneous environment such as Bazel.

Ideally, both rules_cc and apple_support would auto-detect and register their toolchains all the time without the user having to register either. Then, a Starlark setting such as --@rules_cc//cc/toolchain:flavor (name very much TBD) can be used to select between, say, "xcode" and "vanilla", regardless of which order the toolchains were registered in.

[meteorcloudy]

I agree that should be the plan in the long term, but in short term maybe removing the toolchain registration from rules_cc is better for users?
See bazelbuild/rules_cc#199 (comment)

[sgowroji]

Above failures are not shown in the latest CI. Hence we are closing this issue now.