--host_crosstool_top flag

[nghiaho12]

I have a project using bazel=2.1.1, bazel-toolchain=0.5, clang=9.0 and a custom emscripten (WebAssembly) toolchain that's working fine. I'm trying to upgrade everything to the latest and greatest (bazel=4.2.2, bazel-toolchain=0.6.3, clang=13.0).

The problem I'm facing is theeEmscripten tool chain uses this flag --host_crosstool_top=@llvm_toolchain//:toolchain, which no longer works. I've tried --host_crosstool_top=@llvm_toolchain//:cc-toolchain-x86_64-linux but bazel complains with

..../bazel_tools/tools/cpp/BUILD:64:11: in :cc_toolchain attribute of cc_library rule @bazel_tools//tools/cpp:malloc: '@llvm_toolchain//:cc-toolchain-x86_64-linux' does not have mandatory providers: 'ToolchainInfo'. Since this rule was created by the macro 'cc_library', the error might have been caused by the macro implementation ERROR: Analysis of target '//third_party/ilm/ilmbase:half_toFloat' failed; build aborted: Analysis of target '@bazel_tools//tools/cpp:malloc' failed

The emscripten toolchain is based off https://github.com/emscripten-core/emsdk/tree/main/bazel.

[rrbutani]

@nghiaho12 We dropped CROSSTOOL support in 0.6.1; platforms, toolchains, and toolchain resolution seem to be the direction Bazel has been heading in.

In general, adding build --incompatible_enable_cc_toolchain_resolution to your .bazelrc and ensuring llvm_register_toolchains is called in your WORKSPACE file (or manually specifying the toolchains to use with --extra_toolchains) is all that's needed to switch away from using CROSSTOOL with this repo.

---

I'm not totally sure I understand your use case though; are you trying to use the emscripten toolchain for wasm targets and bazel-toolchain for targets built for the host? As far as I know there isn't a way to indicate to toolchain resolution that a particular toolchain is only to be used for "host" targets; the toolchain resolution way to do this is to use platform constraints.

If the above is what you're trying to do I don't think there's a super straightforward solution, unfortunately; flipping on --incompatible_enable_cc_toolchain_resolution will (afaik) break CROSSTOOL with rules_cc (--cpu and friends won't be read anymore) and emsdk's rules seem to just transition crosstool_top.

I think the "right" way to get the two toolchains to coexist is to tweak the emscripten toolchain to use toolchains and constraints (and then to have the wasm_cc_binary rule transition platform to something that has the wasm32/wasm64 CPU constraint); I don't think creating some platform mappings is sufficient. This issue (specifically the migration section) has some more context.

Using the 0.6.0 release may also work.

Let me know if modifying the emscripten toolchain as described above is something you're interested in doing; it should just require adding something like this in lieu of cc_toolchain_suite (with the appropriate constraints), adding some plumbing to register the toolchains, and tweaking the wasm_cc_binary's transition to modify the platform.

[nghiaho12]

This project has some targets that requires building cc_binary with the native host compiler and maybe others, while the rest uses emscripten. Hence the need to support two toolchains.

I can confirm --incompatible_enable_cc_toolchain_resolution does break --cpu.

I tried the 0.6 release but it complains with

...llvm_toolchain/BUILD.bazel:25:19: in toolchains attribute of cc_toolchain_suite rule @llvm_toolchain//:toolchain: rule '@llvm_toolchain//:cc-clang-aarch64-linux' does not exist. Since this rule was created by the macro 'cc_toolchain_suite', the error might have been caused by the macro implementation

The BUILD.bazel shows

cc_toolchain_suite( name = "toolchain", toolchains = { "k8|clang": ":cc-clang-x86_64-linux", "aarch64|clang": ":cc-clang-aarch64-linux", "darwin|clang": ":cc-clang-x86_64-darwin", "k8": ":cc-clang-x86_64-linux", "aarch64": ":cc-clang-aarch64-linux", "darwin": ":cc-clang-x86_64-darwin", }, )

There is indeed no cc-clang-aarch64-linux entry in the file, or any of the darwin and aarch64 stuff.

I'll have a look at trying your suggestions. I'm still getting familiar with Bazel so it's going to take some time.

[siddharthab]

This issue is now obsolete because the emscripten toolchain has changed their approach.