Skip to content

-Z gcc-ld=lld fails again #101653

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
tschuett opened this issue Sep 10, 2022 · 6 comments · Fixed by #101792
Closed

-Z gcc-ld=lld fails again #101653

tschuett opened this issue Sep 10, 2022 · 6 comments · Fixed by #101792
Assignees
Labels
C-bug Category: This is a bug.

Comments

@tschuett
Copy link

I tried this code:

RUSTFLAGS='-Z gcc-ld=lld' cargo +nightly build --release

I expected to see this happen: it builds my crate.

Instead, this happened:

 = note: rust-lld: error: library not found for -lcrt1.10.6.o
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Meta

rustc --version --verbose:

rustc +nightly --version --verbose
rustc 1.65.0-nightly (1120c5e01 2022-09-08)
binary: rustc
commit-hash: 1120c5e01df508de64fe6642f22fadeb574afd6d
commit-date: 2022-09-08
host: x86_64-apple-darwin
release: 1.65.0-nightly
LLVM version: 15.0.0

I found in the invocation of cc

nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/gcc-ld" "-fuse-ld=lld" "--target=x86_64-apple-macosx10.7.0"
> clang --version
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> xcrun --sdk macosx --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
> cc --print-target-triple
x86_64-apple-darwin21.6.0
Backtrace

<backtrace>

See #101504 (comment).

@tschuett tschuett added the C-bug Category: This is a bug. label Sep 10, 2022
@tschuett
Copy link
Author

#100200 introduced the target parameter

@lqd
Copy link
Member

lqd commented Sep 10, 2022

I managed to find an old x64 mac, Xcode 13 on OS 11.6.1, and can reproduce the issue there, so I'll try to look into it.

@lqd lqd self-assigned this Sep 10, 2022
@tschuett
Copy link
Author

>  find /Applications/Xcode.app/Contents/Developer/Platforms -name crt1.10.6.o
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/crt1.10.6.o

There is a crt1.10.6.o file on my system, but it is not a library.

@lqd
Copy link
Member

lqd commented Sep 10, 2022

nightly-2022-09-02 does not reproduce the issue, so it may be a different change from #100200 which landed in the following nightly (in particular the check about the ld flavor; which may need to also check for the ld64 one).

On aarch64-apple-darwin, the LLVM target is arm64-apple-macosx11.0.0, a lot more recent than the one on x64, so maybe that's why it currently works there.

@lqd
Copy link
Member

lqd commented Sep 11, 2022

So removing the --target argument fixes it for me on the x64 machine: it manages to use rust-lld 15.0.0.

On this osx/sdk/etc, clang does find gcc-ld/ld64.lld without the --target mentioned in #97402 (comment).

(Similarly, on the aarch64, it still works and finds ld64.lld without that argument)

I'll make a PR soon.

@Wyvern
Copy link

Wyvern commented Sep 14, 2022

Any progress on it? Nightly build 2022-09-13 still reproduce the problem.

@bors bors closed this as completed in 312c9a3 Jan 3, 2023
compiler-errors added a commit to compiler-errors/rust that referenced this issue Jan 4, 2023
Ensure `lld` is supported with `download-ci-llvm`

This PR:
- ensures LLD's step in bootstrap's dist, but it's not strictly necessary since dist will already package it when it's present.
- makes bootstrap's `native::LLD` step support using the packaged `ci-llvm/bin/lld`, instead of building it from source (which would most likely not be available today, nor in the future where `download-ci-llvm = if-available` is the default).

If I understand correctly, `--enable-full-tools` will also enable `rust.lld`, and this is why LLD is already packaged today in the `rust-dev` component on the main targets (and why `-Zgcc-ld=lld` does work there).

That means it's likely that this PR will not be able to land before I've reworked and landed rust-lang#101792: if LLD is available in `download-ci-llvm`, the `needs-rust-lld` tests should start being executed on the x64 macOS test builders, and CI would fail today.

I've tested locally that building with `download-ci-llvm = true` and `lld = true` with the LLVM submodule unregistered was successful, and that `rust-lld` and the various `lld-wrapper`s are present and `-Zgcc-ld=lld` works as well, on a few different platforms:
- `x86_64-unknown-linux-gnu`
- `aarch64-apple-darwin`
- `x86_64-pc-windows-msvc` (with `-Clinker=rust-lld` rather than `-Zgcc-ld=lld`)
- `x86_64-apple-darwin`, with the `MACOSX_DEPLOYMENT_TARGET` workaround for rust-lang#101653

I don't think we really need to bump the `download-ci-llvm-stamp` in this case, since `./build/$triple/ci-llvm/bin/lld` is present on all the above targets already, but have added it mechanically, and it should probably be removed to avoid unnecessary downloads/churn.

Fixes rust-lang#98340
Supersedes rust-lang#100010
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants