Add missing rustc binaries to rustc_lib filegroup

[avrabe]

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.

[illicitonion]

Thanks!

[havasd]

@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]

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]

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]

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.

[avrabe]

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.

[avrabe]

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!