`-fuse-ld=lld-N` breaks LTO on MinGW, while `-fuse-ld=lld` works fine despite selecting the same linker

[HolyBlackCat]

This only happens on MinGW, if the LLD binary is suffixed with a version number. Since MSYS2 doesn't use the version suffix, this is tricky to test: you can e.g. use Ubuntu and install suffixed LLD from https://apt.llvm.org/, and then cross-compile to MinGW (I've tested via https://github.com/HolyBlackCat/quasi-msys2).

If you compile int main() {} with clang++ 1.cpp -flto -fuse-ld=lld-20, it says:

clang: error: 'x86_64-w64-windows-gnu': unable to pass LLVM bit-code files to linker

But if you use -fuse-ld=lld, it works fine.

The fun part is that if you remove -flto and add -v, it turns out that the same linker gets used in both cases.

-fuse-ld=lld calls /usr/lib/llvm-20/bin/ld.lld, which is a symlink to lld (resolves to /usr/lib/llvm-20/bin/lld), and -fuse-ld=lld-20 calls /usr/bin/ld.lld-20, which is a symlink to ../lib/llvm-20/bin/ld.lld (also resolves to /usr/lib/llvm-20/bin/lld).

Tested on Clang 20.1.7 on Ubuntu, and also on 21.1.1 on FreeBSD.

[Andarwinux]

see mstorsjo/llvm-mingw#379

use -fuse-ld=lld --ld-path=ld.lld-20

[HolyBlackCat]

@Andarwinux I ended up with just -fuse-ld=lld, it seems it manages to find its own bundled LLD version automagically. Thanks for the flag though, didn't know it existed.

[HolyBlackCat]

@MaskRay I do believe this is a bug. -fuse-ld=lld-N should either work correctly or be rejected entirely. It's weird that it works fine for all purposes except LTO specifically.

[MaskRay]

-fuse-ld=lld is supposed to specify the linker flavor, like bfd,gold,lld,mold. clangDriver sometimes has to know the linker flavor and pass different options. --ld-path is the recommended option to specify a linker path.

[HolyBlackCat]

@MaskRay That makes sense, but then I think we should warn if lld-N is passed.