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 🙏

test/unit/native_deps/native_deps_test.bzl

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

cargo/private/cargo_build_script.bzl

-    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

cargo/private/BUILD.bazel

+    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

rust/private/repository_utils.bzl

+    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

rust/private/rustc.bzl

+                    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

rust/private/rustc.bzl

                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

rust/settings/settings.bzl

    )

+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

rust/toolchain.bzl

+
+        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

rust/toolchain.bzl

+            # `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 cerisier/toolchains_llvm_bootstrapped@aaeeacd#diff-5e02a5ab7afca2441282a65cca097c8fade25a1d6d9ffbb71b920c19a1e58babR32-R39 and the corresponding explanation on the Bazel issue

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

cargo/private/BUILD.bazel

+    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

cargo/private/cargo_build_script.bzl

-    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

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

test/unit/native_deps/native_deps_test.bzl Show resolved Hide resolved

dzbarsky reviewed Nov 22, 2025

View reviewed changes

UebelAndre mentioned this pull request Nov 26, 2025

Release 0.68.0 #3739

Open

UebelAndre force-pushed the linker branch 4 times, most recently from 7451d08 to 69cfdd1 Compare December 1, 2025 15:43

Moved rust_allocator_libraries to it's own .bzl file

6a36c15

UebelAndre force-pushed the linker branch from 69cfdd1 to fd8dcd8 Compare December 2, 2025 15:38

UebelAndre added 2 commits December 2, 2025 07:44

Add support for optional cc_toolchain

f3e784f

PR feedback

57d3485

UebelAndre force-pushed the linker branch 3 times, most recently from cdabdcc to 814d054 Compare December 2, 2025 16:41

UebelAndre force-pushed the linker branch from 814d054 to 35c0ba8 Compare December 2, 2025 17:09

Added cross_compile examples

a2ad88a

UebelAndre force-pushed the linker branch from 35c0ba8 to 89e2929 Compare December 2, 2025 17:52

UebelAndre added 2 commits December 2, 2025 10:06

Further isolate need for cc_toolchain

38b2373

Switch to busybox style /bin/false

210c378

UebelAndre force-pushed the linker branch 2 times, most recently 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

Add support for optional cc_toolchain #3665

Are you sure you want to change the base?

Add support for optional cc_toolchain #3665

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

UebelAndre commented Oct 13, 2025 •

edited

Loading