Some `rustc-dev` libraries leak the build path on macOS

[emilazy]

Summary

The LC_ID_DYLIBs of various rustc-dev libraries contain the directory rustc was built in, unlike libstd and so on, which get rewritten to use @rpath.

Command used

Verified with builds from rustup and Nixpkgs. e.g. using otool -D:

/Users/emily/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib//libserde_derive-e7595b45d4ceb7ae.dylib:
/Users/runner/work/rust/rust/build/aarch64-apple-darwin/stage1-rustc/release/deps/libserde_derive-e7595b45d4ceb7ae.dylib
/nix/store/js75pxwpz343nqna2bd6faanyblkzprl-rustc-1.88.0/lib/rustlib/aarch64-apple-darwin/lib/libserde_derive-2b3958020e984e53.dylib:
/nix/var/nix/b/0w6py76s0avzxzrb2didaqypdp/rustc-1.88.0-src/build/aarch64-apple-darwin/stage1-rustc/release/deps/libserde_derive-2b3958020e984e53.dylib

Compare to:

/Users/emily/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-af0f282b96954ac9.dylib:
@rpath/libstd-af0f282b96954ac9.dylib
/nix/store/js75pxwpz343nqna2bd6faanyblkzprl-rustc-1.88.0/lib/rustlib/aarch64-apple-darwin/lib/libstd-a5850b15d56c7b35.dylib:
@rpath/libstd-a5850b15d56c7b35.dylib

This doesn’t apply to all rustc-dev libraries, e.g.

/Users/emily/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_driver-5e95be703972dd19.dylib:
@rpath/librustc_driver-5e95be703972dd19.dylib
/nix/store/js75pxwpz343nqna2bd6faanyblkzprl-rustc-1.88.0/lib/rustlib/aarch64-apple-darwin/lib/librustc_driver-15eb417d0bddcfd9.dylib:
@rpath/librustc_driver-15eb417d0bddcfd9.dylib

Expected behaviour

The same @rpath behaviour as most of the libraries.

Actual behaviour

The build directory leaks.

Bootstrap configuration (bootstrap.toml)

(Observed with both official rustup builds and with Nixpkgs, so I think this shouldn’t matter much. It happens both with and without rust.remap-debuginfo.)

Operating system

macOS 15.6

HEAD

It’s observable with the 1.88.0 tarball used by Nixpkgs and whatever rustup uses as a source. Both are 6b00bc3, apparently.

Additional context

I know there is work being done on the trim-paths stuff, but I think that’s separate to the existing @rpath rewriting, so I’m not sure if it would fix this or not. The LC_ID_DYLIBs do need to be actual paths, I think.

(Let me know if the bootstrap configuration and build log seem super important, but I think this should be easy to reproduce.)

[bjorn3]

Bootstrap uses RUSTFLAGS to pass -Zosx-rpath-install-name to rustc:

rust/src/bootstrap/src/core/builder/cargo.rs

Line 250 in e1b9081

self.rustflags.arg("-Zosx-rpath-install-name");

When you pass --target to cargo (which bootstrap always does even when not cross-compiling), cargo will ignore RUSTFLAGS when compiling for the host. As such all proc-macros that end up in the rustc-dev component don't have -Zosx-rpath-install-name applied to them. This doesn't have any negative effect at runtime as proc-macros are only dlopened anyway and never used as link dependency of another dylib/executable, but as you noticed it does leak the build path.