lld-wrapper fails again

[tschuett]

I tried this code:

RUSTFLAGS='-Z gcc-ld=lld -C target-cpu=native' cargo +nightly build --release

and this happened:

  = note: lld-wrapper: executable has unexpected name: Some("ld64")
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

I expected to see this happen: it would compile my crate.

Instead, this happened: lld failed.

Meta

rustc --version --verbose:

> rustc +nightly --verbose --version
rustc 1.65.0-nightly (8c6ce6b91 2022-09-02)
binary: rustc
commit-hash: 8c6ce6b91b172f77c795a74bfeaf74b865146b3f
commit-date: 2022-09-02
host: x86_64-apple-darwin
release: 1.65.0-nightly
LLVM version: 15.0.0

>  ld -v
@(#)PROGRAM:ld  PROJECT:ld64-764
BUILD 11:29:01 May 17 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.5) (static support for 28, runtime is 28)
TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3)
> clang -v
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

#100200 fixed the problem that I reported in #97755. There seems to be a new problem with an unknown linker name.

Backtrace

<backtrace>

@petrochenkov

[petrochenkov]

@tschuett
Could you post the list of files in the gcc-ld directory in Rust distribution?

[tschuett]

I found in the clang invocation:

"-B/Users/XXXX/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/gcc-ld" "-fuse-ld=lld"

> ls /Users/XXX/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/gcc-ld
ld.lld  ld64.lld  lld-link  wasm-ld

[petrochenkov]

It looks like maybe clang replaces argv[0] and changes it from ld64.lld to ld64 when calling lld-wrapper?

[petrochenkov]

I can't confirm whether that's the case right now, but if that's true then the fix would be as simple as adding the "ld64" alternative to fn get_lld_flavor in lld-wrapper.

[tschuett]

Apple ships its linker as ld. I couldn't find a ld64 file.

[tschuett]

I believe the issue is with the usage of file_stem()in the PR, see:
https://doc.rust-lang.org/stable/std/path/struct.Path.html#method.file_stem
You probably meant to use file_name().

Wait. file_stem() is because of Windows? ld64.lld is the only one that does not play well with it.

One solution is to normalise the string or remove_dot_exe before the match statement.

[lqd]

This is not happening only on osx. I can reproduce this.

It looks like maybe clang replaces argv[0] and changes it from ld64.lld to ld64 when calling lld-wrapper?

The path is correct and unchanged by clang, but it's indeed the file_stem call that trims too much on unixes because of the weird executable name with a dot.

I'll fix it.

[Wyvern]

The -Zgcc-ld=lldproblem still exists, but the error changed to rust-lld: error: library not found for -lcrt1.10.6.o on macos. Need more investigation..