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

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 6b00bc388, 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.)

Reproduce on macOS with otool -D against the affected rustc-dev dylibs, then compare their LC_ID_DYLIB values with libstd and rustc_driver. Trace the existing @rpath rewriting and determine why some libraries retain the build directory. Done means the affected libraries use the expected @rpath form without leaking the build path.