Add rust_objcopy attribute to rust_toolchan by avrabe · Pull Request #3727 · bazelbuild/rules_rust

avrabe · 2025-11-13T05:41:52Z

Summary

Add rust-objcopy and wasm-component-ld to the rustc_lib filegroup in repository_utils.bzl. These binaries are present in recent rustc distributions (wasm-component-ld since 1.82.0, rust-objcopy since 1.84.0) but were not previously declared.

Changes

Binary Declaration: Add rust-objcopy{binary_ext} and wasm-component-ld{binary_ext} to the rustc_lib filegroup glob patterns

Context

On Windows, Bazel copies files into the sandbox rather than symlinking, so only explicitly listed files are available. This caused wasm32-wasip2 builds to fail with linker 'wasm-component-ld.exe' not found.

On Linux/macOS, the issue was masked by symlink-based sandboxing which allowed rustc to access unlisted files in the same directory.

Testing PR bazelbuild/rules_rust#3727 which adds wasm-component-ld.exe and rust-objcopy.exe to rustc_lib filegroup. This should fix Windows wasm32-wasip2 builds by ensuring the linker is copied into the Bazel sandbox. Issue: avrabe/rules_rust#8

illicitonion

Thanks!

havasd · 2025-12-27T22:40:22Z

@illicitonion is there anything which prevents this to be merged? this change is useful for macos as well #3307

UebelAndre

There's now a rust-lld target which has at least wasm-component-ld as a runfile. I think this is a better home for that but don't know exactly where objcopy should go. What about it's own filegroup and adding it as it's own optional attribute to rustc_toolchain?

havasd · 2025-12-29T12:16:53Z

There's now a rust-lld target which has at least wasm-component-ld as a runfile. I think this is a better home for that but don't know exactly where objcopy should go. What about it's own filegroup and adding it as it's own optional attribute to rustc_toolchain?

I agree with you that it would be good to be a separate attribute of the toolchain for objcopy. It would simplify some parts as we have some custom rules for stripping targets.

Unless @avrabe would do it. I could contribute that change.

UebelAndre · 2025-12-29T14:40:52Z

There's now a rust-lld target which has at least wasm-component-ld as a runfile. I think this is a better home for that but don't know exactly where objcopy should go. What about it's own filegroup and adding it as it's own optional attribute to rustc_toolchain?

I agree with you that it would be good to be a separate attribute of the toolchain for objcopy. It would simplify some parts as we have some custom rules for stripping targets.

Unless @avrabe would do it. I could contribute that change.

I'd be happy to review that from whoever wanted to put up the PR 😄

avrabe · 2025-12-30T08:36:22Z

Thanks for the feedback @UebelAndre - updated the approach:

Removed wasm-component-ld from rustc_lib (now covered by rust-lld's *-ld glob)
Added rust-objcopy as its own filegroup + optional toolchain attribute

@havasd thanks for the offer to contribute - I went ahead and made the changes. Hope this looks better now.

PR #3727 (bazelbuild/rules_rust#3727) is still open in upstream rules_rust. The previous commit incorrectly removed the fork override, breaking Windows builds. The fork at avrabe/rules_rust includes the fix that adds wasm-component-ld.exe to the rustc_lib filegroup, which is required for Windows WASM component builds. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Override rules_rust 0.68.1 with fork that fixes the bug where target_files parameter was ignored in _symlink_sysroot_tree. This ensures wasm-component-ld is symlinked into the sysroot, fixing Windows builds for wasm32-wasip2 targets. See: bazelbuild/rules_rust#3727 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

avrabe · 2025-12-31T19:30:11Z

Updated with additional fixes for wasm-component-ld support:

Commit 1: Add rust-objcopy as optional toolchain attribute (as requested)

Commit 2: Fix sysroot construction for linker tools

_symlink_sysroot_tree was ignoring the target_files parameter, using target.files instead - this prevented wasm-component-ld and gcc-ld/* from being symlinked into the sysroot
The linker was placed at {sysroot}/bin/ but rustc adds {sysroot}/lib/rustlib/{host}/bin/ to PATH when invoking linkers (rustc source). Now extracts the correct path from the source location.

wasm-component-ld searches PATH for wasm-ld or rust-lld (source), so the linker must be in the directory that rustc adds to PATH.

These fixes enable wasm-component-ld to find rust-lld on Windows where Bazel's manifest-based runfiles don't provide the same fallback paths as Unix symlinks.

PR #3727 (bazelbuild/rules_rust#3727) is still open in upstream rules_rust. The previous commit incorrectly removed the fork override, breaking Windows builds. The fork at avrabe/rules_rust includes the fix that adds wasm-component-ld.exe to the rustc_lib filegroup, which is required for Windows WASM component builds. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Override rules_rust 0.68.1 with fork that fixes the bug where target_files parameter was ignored in _symlink_sysroot_tree. This ensures wasm-component-ld is symlinked into the sysroot, fixing Windows builds for wasm32-wasip2 targets. See: bazelbuild/rules_rust#3727 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Adds `rust-objcopy` as a separate filegroup and optional attribute on `rust_toolchain`, following the same pattern as `rust-lld`. The filegroup is only generated when rust-objcopy is available (Rust 1.84.0+).

- Use target_files parameter instead of target.files in loop - Place linker at lib/rustlib/{triple}/bin/ so rustc's PATH includes it Fixes wasm-component-ld failing to find rust-lld on Windows.

avrabe · 2026-02-04T04:12:36Z

Hi @UebelAndre - I think I accidentally disabled auto-merge when rebasing. All CI is green and I've addressed your feedback. Could you re-enable auto-merge or re-review when you get a chance? Thanks!

UebelAndre

I'm so sorry about the delay here! Thank you so much for the change!

## Summary Add `rust-objcopy` and `wasm-component-ld` to the `rustc_lib` filegroup in `repository_utils.bzl`. These binaries are present in recent rustc distributions (wasm-component-ld since 1.82.0, rust-objcopy since 1.84.0) but were not previously declared. ### Changes - **Binary Declaration**: Add `rust-objcopy{binary_ext}` and `wasm-component-ld{binary_ext}` to the rustc_lib filegroup glob patterns ### Context On Windows, Bazel copies files into the sandbox rather than symlinking, so only explicitly listed files are available. This caused wasm32-wasip2 builds to fail with `linker 'wasm-component-ld.exe' not found`. On Linux/macOS, the issue was masked by symlink-based sandboxing which allowed rustc to access unlisted files in the same directory. --------- Co-authored-by: UebelAndre <github@uebelandre.com>

bazelbuild#3727 added a `rust_objcopy` attribute to `rust_toolchain`, a separate `rust-objcopy` filegroup in the compiler repo BUILD, and automatic opt-in for Rust 1.84+/recent nightlies. But the glue to turn that attribute into a real action input is missing: `ctx.file.rust_objcopy` is stashed on ToolchainInfo and never used again. It never flows through `_generate_sysroot` into `direct_files`, so it doesn't land in `toolchain.all_files` and isn't declared as an input to the Rustc action. On Linux/macOS with symlink-based sandboxing this is masked — rustc happens to see the neighboring file in the unsandboxed rules_rust external repo. Under remote execution, Windows (file-copy sandbox), or stricter local sandboxes, rustc invokes `rust-objcopy` and fails with: error: unable to run `rust-objcopy`: No such file or directory Thread: bazelbuild#3307 Fix: mirror the `linker` handling — symlink `rust_objcopy` into the generated sysroot at its sibling-of-rustc path (`lib/rustlib/<triple>/bin/rust-objcopy`, which is where rustc looks) and add the symlink to `direct_files` so it joins `all_files` and becomes a declared Rustc action input. Verified by: - Patched rules_rust via `local_path_override` in a minimal smoke workspace using rustc 1.93.0, aarch64-apple-darwin. - `bazel build -c opt //:hello` succeeds (regression: opt-mode process_wrapper uses `-Cstrip=debuginfo`, which invokes rust-objcopy). - `bazel aquery 'mnemonic("Rustc", //:hello)'` now lists the sysroot rust-objcopy symlink as a declared input (was absent before).

## Summary #3727 added a `rust_objcopy` attribute to `rust_toolchain`, a separate `rust-objcopy` filegroup, and automatic opt-in for Rust 1.84+/recent nightlies. But the glue to turn that attribute into a real action input is missing: `ctx.file.rust_objcopy` is stashed on `ToolchainInfo` and never used again. It never flows through `_generate_sysroot` into `direct_files`, so it doesn't join `toolchain.all_files` and isn't declared as an input to the Rustc action. On Linux/macOS with symlink-based sandboxing this is masked — rustc happens to see the neighboring file in the unsandboxed `rules_rust` external repo. Under remote execution, Windows (file-copy sandbox), or stricter local sandboxes, rustc invokes `rust-objcopy` and fails: ``` error: unable to run `rust-objcopy`: No such file or directory (os error 2) ``` Tracking: #3307. ## Fix Mirror the `linker` handling in `_generate_sysroot`: symlink `rust_objcopy` into the sysroot at `lib/rustlib/<triple>/bin/rust-objcopy` (where rustc looks) and append it to `direct_files` so it becomes a declared Rustc action input. ## Verification Patched `rules_rust` via `local_path_override` in a minimal smoke workspace using rustc 1.93.0 on aarch64-apple-darwin: - `bazel build -c opt //:hello` succeeds (opt-mode `process_wrapper` uses `-Cstrip=debuginfo`, which invokes rust-objcopy). - `bazel aquery 'mnemonic("Rustc", //:hello)'` now lists the sysroot `rust-objcopy` symlink as a declared input — it was absent before. Before: no `rust-objcopy` entry in the Rustc action inputs. After: `bazel-out/.../rust_toolchain/lib/rustlib/aarch64-apple-darwin/bin/rust-objcopy`.

avrabe force-pushed the fix/add-missing-rustc-binaries branch from 738871d to b715cc7 Compare November 13, 2025 05:52

avrabe mentioned this pull request Nov 13, 2025

Windows: wasm-component-ld.exe missing from rustc_lib filegroup causes wasm32-wasip2 builds to fail avrabe/rules_rust#8

Open

avrabe force-pushed the fix/add-missing-rustc-binaries branch from b715cc7 to 030a4cf Compare December 4, 2025 05:55

illicitonion approved these changes Dec 15, 2025

View reviewed changes

illicitonion force-pushed the fix/add-missing-rustc-binaries branch from 030a4cf to 2b63294 Compare December 15, 2025 20:57

UebelAndre requested changes Dec 29, 2025

View reviewed changes

avrabe force-pushed the fix/add-missing-rustc-binaries branch from 2b63294 to 3563a3d Compare December 30, 2025 08:34

avrabe force-pushed the fix/add-missing-rustc-binaries branch from 3563a3d to 1720224 Compare December 30, 2025 08:40

avrabe force-pushed the fix/add-missing-rustc-binaries branch from f34108f to c30cafc Compare December 31, 2025 15:38

avrabe force-pushed the fix/add-missing-rustc-binaries branch 7 times, most recently from 7ae12cf to e25e6cb Compare January 21, 2026 05:13

UebelAndre enabled auto-merge January 22, 2026 01:51

avrabe added 2 commits January 27, 2026 06:36

Add rust-objcopy as optional rust_toolchain attribute

1755e79

Adds `rust-objcopy` as a separate filegroup and optional attribute on `rust_toolchain`, following the same pattern as `rust-lld`. The filegroup is only generated when rust-objcopy is available (Rust 1.84.0+).

Fix _symlink_sysroot_tree and linker sysroot path

1241b83

- Use target_files parameter instead of target.files in loop - Place linker at lib/rustlib/{triple}/bin/ so rustc's PATH includes it Fixes wasm-component-ld failing to find rust-lld on Windows.

auto-merge was automatically disabled January 27, 2026 05:36
Head branch was pushed to by a user without write access

avrabe force-pushed the fix/add-missing-rustc-binaries branch from e6d2f0e to 1241b83 Compare January 27, 2026 05:36

Merge branch 'main' into fix/add-missing-rustc-binaries

6d9e865

UebelAndre approved these changes Mar 7, 2026

View reviewed changes

UebelAndre enabled auto-merge March 7, 2026 05:06

UebelAndre added this pull request to the merge queue Mar 7, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Mar 7, 2026

UebelAndre added this pull request to the merge queue Mar 7, 2026

Merged via the queue into bazelbuild:main with commit 6281d27 Mar 7, 2026
3 checks passed

UebelAndre changed the title ~~Add missing rustc binaries to rustc_lib filegroup~~ Add rust_objcopy attribute to rust_toolchan Mar 7, 2026

UebelAndre mentioned this pull request Mar 25, 2026

rules_rust can't bootstrap using remote execution #3307

Open

brianduff mentioned this pull request Apr 16, 2026

Wire rust_objcopy into the generated sysroot action inputs #3972

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add rust_objcopy attribute to rust_toolchan#3727

Add rust_objcopy attribute to rust_toolchan#3727
UebelAndre merged 3 commits intobazelbuild:mainfrom
avrabe:fix/add-missing-rustc-binaries

avrabe commented Nov 13, 2025 •

edited

Loading

Uh oh!

illicitonion left a comment

Uh oh!

havasd commented Dec 27, 2025 •

edited

Loading

Uh oh!

UebelAndre left a comment

Uh oh!

havasd commented Dec 29, 2025 •

edited

Loading

Uh oh!

UebelAndre commented Dec 29, 2025

Uh oh!

avrabe commented Dec 30, 2025

Uh oh!

avrabe commented Dec 31, 2025

Uh oh!

avrabe commented Feb 4, 2026

Uh oh!

UebelAndre left a comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

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

Uh oh!

Summary

Changes

Context

Uh oh!

illicitonion left a comment

Choose a reason for hiding this comment

Uh oh!

havasd commented Dec 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

UebelAndre left a comment

Choose a reason for hiding this comment

Uh oh!

havasd commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

UebelAndre commented Dec 29, 2025

Uh oh!

avrabe commented Dec 30, 2025

Uh oh!

avrabe commented Dec 31, 2025

Uh oh!

avrabe commented Feb 4, 2026

Uh oh!

UebelAndre left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

avrabe commented Nov 13, 2025 •

edited

Loading

havasd commented Dec 27, 2025 •

edited

Loading

havasd commented Dec 29, 2025 •

edited

Loading