Add support for optional cc_toolchain#3665

UebelAndre · 2025-10-13T04:13:59Z

Changes:

Moved rust_allocator_libraries rule implementation into it's own file
Updated all rules to set mandatory = False for @bazel_tools//tools/cpp:toolchain_type toolchains.
Refactored rules_rust internals to work in cases where find_cc_toolchain returns None
Added linker as an optional attribute to rust_toolchain. This is expected to be rust-lld for now.
Added a new setting @rules_rust//rust/settings:toolchain_linker_preference which in the event rust_toolchain.linker and a cc_toolchain are present, chooses the linker to use. (Defaults to cc).
Introduce --@rules_rust//settings:default_allocator_library as a flag to globally control this value.

UebelAndre · 2025-11-21T20:55:28Z

@illicitonion @krasimirgg curious about your thoughts here 🙏

dzbarsky · 2025-11-22T15:30:39Z

-    if include:
-        env["INCLUDE"] = include
+    # Defaults for cxx flags.
+    env["CC"] = "${{pwd}}/{}".format(ctx.executable._fallback_cc.path)


nit: can we define these inside the build_script_runner executable to avoid passing extra env vars we don't need?

#3665 (comment) for this reason I think this is harder than it's worth or spreads out configuration definitions.

ok, we can punt for now. In general I want us to stop using .path as that makes path-mapping not work, so many times we are building crates in multiple configurations even when not really necessary. But lets address in followups

dzbarsky · 2025-11-22T15:31:22Z

+    name = "no_ar",
+    srcs = ["no_binary.rs"],
+    edition = "2021",
+    rustc_env = {


nit: Can we take the busybox approach? build a single copy of this, symlink it a few times, and then look at argv[0] to get the name it was invoked with?

It's a bit trickier to do so since I'd either need to write tempdir logic or come up with some heuristic for where to put these files where I feel this approach is more stable.

Why do you need a TMPDIR? You can define the targets exactly as now, in this package. Just change the rule to be a copy_file(symlink=True) instead of a brand new binary

Updated! I'm nervous about symlink=True as I don't trust symlinks to work on windows. E.g. bazelbuild/bazel#21747

dzbarsky · 2025-11-22T15:33:12Z

+    linker_label = "None"
+    linker_type = "None"
+    if include_linker:
+        linker_label = "\"//:rust-lld\""


might be a bit cleaner to do

linker_label = None if include_linker: linker_label = "//:rust-lld" ... template.format(linker_label = repr(linker_label))

dzbarsky · 2025-11-22T15:40:27Z

+                    skip_next = False
+                    continue
+
+                # Strip -Wl, prefix if using direct driver (it's only for compiler drivers)


in my mind this is another +1 to switching to cc_common.link :)

dzbarsky · 2025-11-22T15:46:12Z

                cc_toolchain.static_runtime_lib(feature_configuration = feature_configuration),
-                map_each = get_lib_name,
-                format_each = "-lstatic=%s",
+                map_each = _get_dirname,


do we actually need to use these -L or can we just pass static_runtime_lib directly so it expands to the actual libs

We could probably pass static_runtime_lib but my changes here are mostly cleanup so I wouldn't want to include that in this PR.

dzbarsky · 2025-11-22T15:47:38Z

    )

+def toolchain_linker_preference():
+    """A flag to control which linker is preferred for linking Rust binaries.


can you expand this a bit to explain the difference between this setting and the cc_common.link one? i.e. what's the difference between enabling that and setting this one to cc? I'm worried that we're getting so many different linker options

maybe the options should be "rust means rust linker, cc means use cc_common.link" so there's fewer possibilities?

Yeah, this parameter is a bit awkward. The idea is that even if you have both provided rust_toolchain.linker and a cc_toolchain is configured, that you can be explicit about what linker you'd like to use. The primary use case is just to force the use of rust_toolchain.linker even when a cc_toolchain is defined.

dzbarsky · 2025-11-22T15:49:36Z

+
+        sysroot_linker = _symlink_sysroot_bin(ctx, name, dest, linker_bin)
+        sysroot_linker_files = _symlink_sysroot_tree(ctx, name, linker, linker[DefaultInfo].default_runfiles.files)
+        direct_files.extend([sysroot_linker])


nit: direct_files.append, same on the line below

dzbarsky · 2025-11-22T15:54:30Z

+            # `target` cfg is used so a linker can be chose based on the target
+            # platform. Linker binaries are still required to be runnable in the
+            # `exec` configuration.
+            cfg = "target",


this doesn't seem right, I think what you want is set cfg = "exec" but instantiate it as

linker = select({ "@platforms//...": ... })

and, interestingly enough, the select will be evaluated against the target platform, because it's resolved before the exec transition is applied. See hermeticbuild/hermetic-llvm@aaeeacd#diff-5e02a5ab7afca2441282a65cca097c8fade25a1d6d9ffbb71b920c19a1e58babR32-R39 and the corresponding explanation on the Bazel issue

dzbarsky · 2025-12-02T18:54:59Z

+    visibility = ["//visibility:public"],
+)
+
+copy_file(


If you use the version from https://registry.bazel.build/docs/bazel_lib, allow_symlink = True is safe.

That would require adding a new dependency which I'd really like to avoid. There's some TODOs referring to bazelbuild/bazel#21747 that I'd like to clean up at some point and this could be one of the things visited in that change.

Ok let's leave a TODO. Realistically that's a pretty lightweight dep and probably most projects already pull it in :)

dzbarsky · 2025-12-02T18:56:28Z

-    if include:
-        env["INCLUDE"] = include
+    # Defaults for cxx flags.
+    env["CC"] = "${{pwd}}/{}".format(ctx.executable._fallback_cc.path)


ok, we can punt for now. In general I want us to stop using .path as that makes path-mapping not work, so many times we are building crates in multiple configurations even when not really necessary. But lets address in followups

illicitonion

Works for me! Thank you!

Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>

After #3665 there should no longer be a need to register a fake cc_toolchain to target wasm platforms. closes #1601

UebelAndre force-pushed the linker branch 3 times, most recently from 7cc8279 to ff94a0b Compare October 13, 2025 22:52

UebelAndre force-pushed the linker branch 6 times, most recently from c7dccbf to 95a3d34 Compare October 20, 2025 22:44

UebelAndre force-pushed the linker branch 3 times, most recently from 92d42c4 to 43b8276 Compare November 21, 2025 20:33

UebelAndre requested review from illicitonion and krasimirgg November 21, 2025 20:55

UebelAndre marked this pull request as ready for review November 21, 2025 20:55

UebelAndre commented Nov 21, 2025

View reviewed changes

Comment thread test/unit/native_deps/native_deps_test.bzl

dzbarsky reviewed Nov 22, 2025

View reviewed changes

UebelAndre mentioned this pull request Nov 26, 2025

Release 0.68.0 #3739

Merged

UebelAndre force-pushed the linker branch 11 times, most recently from 89e2929 to 210c378 Compare December 2, 2025 18:06

UebelAndre force-pushed the linker branch from be68df1 to 210c378 Compare December 2, 2025 18:18

UebelAndre requested a review from dzbarsky December 2, 2025 18:43

dzbarsky reviewed Dec 2, 2025

View reviewed changes

dzbarsky approved these changes Dec 2, 2025

View reviewed changes

illicitonion approved these changes Dec 4, 2025

View reviewed changes

Comment thread .bazelci/presubmit.yml Outdated

Comment thread .bazelci/presubmit.yml Outdated

Comment thread .bazelci/presubmit.yml Outdated

UebelAndre and others added 6 commits December 5, 2025 07:59

Add support for optional cc_toolchain

be51d20

PR feedback

7e23e9d

Added cross_compile examples

9c45646

Further isolate need for cc_toolchain

34137e7

Switch to busybox style /bin/false

8320e8a

Apply suggestions from code review

6ebf7ce

Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>

UebelAndre force-pushed the linker branch from df1260c to 6ebf7ce Compare December 5, 2025 15:59

UebelAndre enabled auto-merge December 5, 2025 15:59

UebelAndre added this pull request to the merge queue Dec 5, 2025

Merged via the queue into bazelbuild:main with commit 6153ba1 Dec 5, 2025
3 checks passed

UebelAndre mentioned this pull request Feb 20, 2026

Dummy CC toolchain for wasm32 #2764

Closed

UebelAndre mentioned this pull request Mar 7, 2026

Delete "dummy" wasm cc_toolchain #3892

Merged

github-merge-queue Bot pushed a commit that referenced this pull request Mar 22, 2026

Delete "dummy" wasm cc_toolchain (#3892)

a60584b

After #3665 there should no longer be a need to register a fake cc_toolchain to target wasm platforms. closes #1601

Conversation

UebelAndre commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

UebelAndre commented Nov 21, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

illicitonion left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

UebelAndre commented Oct 13, 2025 •

edited

Loading