lld-link library search should be case-insensitive for compatibility with MSVC artifacts

[rnk]

MSVC tools produce .obj files that refer to MSVCRT, OLDNAMES, and LIBCMT, but they distribute files with lower-cased names:

$ cl  -c t.cpp   && dumpbin -directives t.obj | grep -i defaul
Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34123 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

t.cpp
   /DEFAULTLIB:libcpmt
   /DEFAULTLIB:LIBCMT
   /DEFAULTLIB:OLDNAMES

$ cl -MD  -c t.cpp   && dumpbin -directives t.obj | grep -i defaul
Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34123 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

t.cpp
   /DEFAULTLIB:msvcprt
   /DEFAULTLIB:MSVCRT
   /DEFAULTLIB:OLDNAMES

$ ls /c/Program\ Files/Microsoft\ Visual\ Studio/2022/Professional/VC/Tools/MSVC/14.41.34120/lib/x64/
aligned_new.lib                                 libcmt.lib                    msvcmrtd.lib
...
clang_rt.fuzzer_MT-x86_64.lib                   libconcrtd1.amd64.pdb         oldnames.lib

Clang and LLVM use lower-cased filenames for auto-linking:

$ git grep -i oldnames ../clang ../llvm
../clang/lib/Driver/ToolChains/Clang.cpp:    CmdArgs.push_back("--dependent-lib=oldnames");
...

This presents a portability problem when cross-linking for Windows from Linux or other case-sensitive platforms. Ideally, LLD should be able to handle MSVC-produced artifacts as they are. We could make this as simple as checking for lower-cased filenames as part of our findFile implementation.

I was almost certain there was already an issue covering this, but github issue search isn't that great, and I hoped that as I started to file this one, it would magically point me to "similar issues", but I've made it this far and it hasn't done that yet, so I'm hitting Create...

[llvmbot]

@llvm/issue-subscribers-lld-coff

Author: Reid Kleckner (rnk)

MSVC tools produce `.obj` files that refer to `MSVCRT`, `OLDNAMES`, and `LIBCMT`, but they distribute files with lower-cased names: ``` $ cl -c t.cpp && dumpbin -directives t.obj | grep -i defaul Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34123 for x64 Copyright (C) Microsoft Corporation. All rights reserved.

t.cpp
/DEFAULTLIB:libcpmt
/DEFAULTLIB:LIBCMT
/DEFAULTLIB:OLDNAMES

$ cl -MD -c t.cpp && dumpbin -directives t.obj | grep -i defaul
Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34123 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

t.cpp
/DEFAULTLIB:msvcprt
/DEFAULTLIB:MSVCRT
/DEFAULTLIB:OLDNAMES

$ ls /c/Program\ Files/Microsoft\ Visual\ Studio/2022/Professional/VC/Tools/MSVC/14.41.34120/lib/x64/
aligned_new.lib libcmt.lib msvcmrtd.lib
...
clang_rt.fuzzer_MT-x86_64.lib libconcrtd1.amd64.pdb oldnames.lib

Clang and LLVM use lower-cased filenames for auto-linking:

$ git grep -i oldnames ../clang ../llvm
../clang/lib/Driver/ToolChains/Clang.cpp: CmdArgs.push_back("--dependent-lib=oldnames");
...

This presents a portability problem when cross-linking for Windows from Linux or other case-sensitive platforms. Ideally, LLD should be able to handle MSVC-produced artifacts as they are. We could make this as simple as checking for lower-cased filenames as part of our `findFile` implementation.

I was almost certain there was already an issue covering this, but github issue search isn't that great, and I hoped that as I started to file this one, it would magically point me to "similar issues", but I've made it this far and it hasn't done that yet, so I'm hitting Create...
</details>

[tru]

This would be nice. I ran into this problem once and did symlinks to cover all the cases, but it would be nice if lld handled it instead.

[mstorsjo]

Just for some extra context here; Clang also suffers from the same issue. There, one can do the symlink (or lowercase everything, including the headers themselves) route, but one can also set up an overlay yaml which makes resolving case insensitive - see https://github.com/llvm/llvm-project/blob/llvmorg-21-init/llvm/cmake/platforms/WinMsvc.cmake#L285-L293 for reference.

If we come up with some neat solution to this in LLD, it would be extra nice if it could be extended to Clang as well.