-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MVP for using rust-lld as part of cc #85961
Conversation
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
c73185a
to
577c4a9
Compare
This comment has been minimized.
This comment has been minimized.
577c4a9
to
8a18c02
Compare
This comment has been minimized.
This comment has been minimized.
8a18c02
to
3ad7450
Compare
This comment has been minimized.
This comment has been minimized.
Hmm, it looks like the test passed on my machine because I had |
08bad9b
to
2f5cde9
Compare
This comment has been minimized.
This comment has been minimized.
2f5cde9
to
7083fe4
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
f3e5550
to
a5e8dc4
Compare
ignore test if rust-lld not found create ld -> rust-lld symlink at build time instead of run time for testing in ci copy instead of symlinking remove linux check test for linker, suggestions from bjorn3 fix overly restrictive lld matcher use -Zgcc-ld flag instead of -Clinker-flavor refactor code adding lld to gcc path revert ci changes suggestions from petrochenkov rename gcc_ld to gcc-ld in dirs
910f416
to
2a76762
Compare
I've fixed the conflict (it was just merging the import sets from the new master and my PR). |
@bors r+ |
📌 Commit 2a76762 has been approved by |
☀️ Test successful - checks-actions |
@petrochenkov I was trying to dogfood my own PR, and I realized that I copied "rust-lld" as "rust-lld" instead of "ld" in gcc_ld_dir in Edit: I renamed "rust-lld" to "ld" in my local copy of the nightly toolchain and I get errors that look like
|
@1000teslas
Looks like the file passes the |
Are you talking about the copy of |
…chenkov copy rust-lld as ld in dist Fixes bug in rust-lang#85961. Linking seems to work for pure Rust projects, but not when a C library needs to be dynamically linked.
Make `-Z gcc-ld=lld` work for Apple targets `-Z gcc-ld=lld` was introduced in rust-lang#85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work. In order to solve this patch does: * Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format. * Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld. * If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation. Fixes rust-lang#86945.
Make `-Z gcc-ld=lld` work for Apple targets `-Z gcc-ld=lld` was introduced in rust-lang#85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work. In order to solve this patch does: * Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format. * Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld. * If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation. Fixes rust-lang#86945.
Make `-Z gcc-ld=lld` work for Apple targets `-Z gcc-ld=lld` was introduced in rust-lang#85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work. In order to solve this patch does: * Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format. * Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld. * If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation. Fixes rust-lang#86945.
Make `-Z gcc-ld=lld` work for Apple targets `-Z gcc-ld=lld` was introduced in rust-lang#85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work. In order to solve this patch does: * Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format. * Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld. * If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation. Fixes rust-lang#86945.
Make `-Z gcc-ld=lld` work for Apple targets `-Z gcc-ld=lld` was introduced in rust-lang#85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work. In order to solve this patch does: * Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format. * Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld. * If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation. Fixes rust-lang#86945.
Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using
echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl,-v
(thanks to bjorn3 on Zulip), I can see that lld is used, but I'm not sure how to inspect that output in a test.