Skip to content
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

Fix -Zgcc-ld=lld #101504

Merged
merged 3 commits into from
Sep 8, 2022
Merged

Fix -Zgcc-ld=lld #101504

merged 3 commits into from
Sep 8, 2022

Conversation

lqd
Copy link
Member

@lqd lqd commented Sep 6, 2022

-Zgcc-ld=lld is currently broken. CI is currently ignoring its tests.

cc @Mark-Simulacrum on the compiletest change: I'm not sure which of bootstrap's test step or compiletest is currently incorrect wrt windows' --compile-lib-path. Since sysroot/bin is passed on windows, that means that compiletest can't find rust-lld on windows and tests are currently ignored: it's looking for something that is in sysroot/lib instead.

They are currently ignored on unixes for a different reason: the lld wrapper has a different name than what is checked.

(I've changed compiletest in this PR, just because I could make a very targeted change there, whereas completely changing the intentional lib path that is passed seemed it'd have wider reaching implications on all tests.)

And in both unix/win cases, I've changed the detection to look for rust-lld rather than the wrappers in bin/gcc-ld/. It seems like the more stable of all these executable names.

r? @petrochenkov

I've tested the lld-wrapper change on linux and osx, but couldn't test on windows gnu targets (I only have MSVC targets, and these can't use rust-lld via -Zgcc-ld=lld, nor do they use the lld wrapper IIUC).

I'd expect it to work whether or not the wrapper is called with or without an executable suffix. But at least now CI should test it in these targets.

Fixes #101370.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 6, 2022
@petrochenkov
Copy link
Contributor

I've tested the lld-wrapper change on linux and osx, but couldn't test on windows gnu targets

I tested it on windows-gnu in the previous PR.
(That's why I missed the fact that ld.lld looks like an extension even without the .exe.)

@petrochenkov
Copy link
Contributor

Thanks!
r=me with #101504 (comment) addressed.
@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 7, 2022
now that CI correctly detects rust-lld in run-make tests, we ignore this
test since it relies on `-Zgcc-ld=lld` which is not made to work on the
windows-msvc targets: it requires a gcc flavor.
@lqd
Copy link
Member Author

lqd commented Sep 7, 2022

@bors r=petrochenkov rollup=never

Could be safe to rollup, but you never know with run-make tests here, especially since they were ignored before, and may require new directives for some platforms.

@bors
Copy link
Contributor

bors commented Sep 7, 2022

📌 Commit 318d0eb has been approved by petrochenkov

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Sep 7, 2022

🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 7, 2022
@bors
Copy link
Contributor

bors commented Sep 8, 2022

⌛ Testing commit 318d0eb with merge 44adfcc...

@bors
Copy link
Contributor

bors commented Sep 8, 2022

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 44adfcc to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 8, 2022
@bors bors merged commit 44adfcc into rust-lang:master Sep 8, 2022
@rustbot rustbot added this to the 1.65.0 milestone Sep 8, 2022
@lqd lqd deleted the rust-lld-fix branch September 8, 2022 08:11
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (44adfcc): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.1% [2.1%, 2.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.3%] 1
All ❌✅ (primary) - - 0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean1 range count2
Regressions ❌
(primary)
2.4% [2.4%, 2.4%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.0% [-2.0%, -2.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-2.0%, 2.4%] 2

Footnotes

  1. the arithmetic mean of the percent change 2

  2. number of relevant changes 2

@Wyvern
Copy link

Wyvern commented Sep 9, 2022

Using the latest nightly build, -Zgcc-ld=lld still raise rust-lld: error: library not found for -lcrt1.10.6.o on macos, any progress? or how to fix it..

@petrochenkov
Copy link
Contributor

@Wyvern
I'm not familiar with Apple targets specifics, @Thog may know more details about this, maybe some SDK options are not set correctly.

Also, does the same error happen if you use -Clink-arg=-fuse-ld=lld instead of -Zgcc-ld? (In that case the system-installed LLD should be used instead of LLD shipped with Rust.)

@lqd
Copy link
Member Author

lqd commented Sep 9, 2022

Interesting. I've tested the PR on an M1 with macOS 12.5.1: it correctly linked a helloworld. CI should also test it now on the osx builders, and the one test using it passes locally.

I've now also checked the latest nightly on the same machine, and the helloworld still runs.

   Compiling helloworld v0.1.0 (/Users/lqd/rust/helloworld)
INFO rustc_codegen_ssa::back::link preparing Executable to "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde"
INFO rustc_codegen_ssa::back::link "cc" "-arch" "arm64" "/var/folders/4b/s50qhh6d2y97mzd0y1rb353r0000gn/T/rustcR7Ng92/symbols.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.13em2l8fldm2p1jc.rcgu.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.1np8s6atvp33s0ra.rcgu.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.1o33xk8vzeiekk33.rcgu.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.3s1pa8gbmcjyyrze.rcgu.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.4vxn2wupg8u0o3gz.rcgu.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.uwkzydvjj86erg7.rcgu.o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde.5catf9dn17imunax.rcgu.o" "-L" "/Users/lqd/rust/helloworld/target/debug/deps" "-L" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-3019167bb774d6f7.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-5d6c50a5511d5b38.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-44703751ec754c6f.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libmemchr-d6f3bfbb73711004.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-44af0db03be329d2.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-9dc78b50bf1c45c0.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-8697aceef2377a94.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd_detect-2af5cab8ea27cc2f.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-a80be289d3b85f20.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libminiz_oxide-85181678fc783242.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libadler-4e642e6b12910c5b.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-b67175a3e890da31.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-1ba63ac4e9539424.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-58428a237963e73e.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-7512abb04e6cb940.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-880986a981365e05.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-a8a859a864856684.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-908209eee60fb642.rlib" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-cb46d4fa30adb098.rlib" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" "-B/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin/gcc-ld" "-fuse-ld=lld" "--target=arm64-apple-macosx11.0.0" "-L" "/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/Users/lqd/rust/helloworld/target/debug/deps/helloworld-3da1fa3e82377dde" "-Wl,-dead_strip" "-nodefaultlibs" "-Wl,-v"
INFO rustc_codegen_ssa::back::link linker stderr:
rust-lld: warning: directory not found for option -L/usr/local/lib
LLD 15.0.0
Library search paths:
	/Users/lqd/rust/helloworld/target/debug/deps
	/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib
	/Users/lqd/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks

INFO rustc_codegen_ssa::back::link linker stdout:

    Finished dev [unoptimized + debuginfo] target(s) in 0.32s
     Running `target/debug/helloworld`
Hello, world!

(You can see this is our rust-lld 15.0.0 so -Zgcc-ld=lld looks to be working in this example)

Something more subtle is probably happening. I feel we've seen some similar errors on CI when linking with clang and LTO recently.

I've also tested more complicated examples using tokio (mini-redis) and that also worked (with and without fat/thin LTO, so it may not be related).

@Wyvern if you could open a dedicated issue with an example that reproduces your error, that'd be great. We'll look into it: if we need to ping the osx experts, a reproducible example, with OS/Xcode/LLVM details (for example I know -Zgcc-ld=lld does not work on an older osx version I have, because of a different error though) will be necessary to explain the context and to test possible fixes. Thanks in advance.

@tschuett
Copy link

tschuett commented Sep 9, 2022

Please ping me on the new issue. I have the same problem. x86 OSX.

@marysaka
Copy link
Contributor

Using the latest nightly build, -Zgcc-ld=lld still raise rust-lld: error: library not found for -lcrt1.10.6.o on macos, any progress? or how to fix it..

I'm not to familiar with usage of -Zgcc-ld=lld but this sound like a missing SDK sysroot injection... though it should select it by default if you target macOS.
What is your target macOS version and what is the host macOS version?
Also what is the output of xcrun --sdk macosx --show-sdk-path?

@tschuett
Copy link

In the cc invocation I found:

 "-fuse-ld=lld" "--target=x86_64-apple-macosx10.7.0"

but

> cc --print-target-triple
x86_64-apple-darwin21.6.0
> xcrun --sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk

This is OSX 12.5.1.

@marysaka
Copy link
Contributor

I was under the impression that you couldn't target this kind of version without a compatible SDK, I might be wrong though.

Another thing that looks odd to me: why explicitly giving the version of macOS you are targeting in the target? The normal way of doing it is with MACOSX_DEPLOYMENT_TARGET otherwise you may have a mismatch between Rust and the version provided to the linker.

Finally, -fuse-ld=lld is wrong as on macOS lld doesn't exist (it's ld directly) except if you are using a vanilla LLVM installation

@Wyvern
Copy link

Wyvern commented Sep 10, 2022

The last "-Zgcc-ld=lld" working normally Rust build was nightly-2022-09-02-x86_64-apple-darwin, after that the error begin to pop up.

At first, it was lld-wrapper: executable has unexpected name: Some("ld64") ref #101370
then became to rust-lld: error: library not found for -lcrt1.10.6.o.

All errors happened on the same macos without LLVM installed.

@tschuett
Copy link

I filed a new issue to continue the discussion:
#101653

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lld-wrapper fails again
9 participants