[Driver][Windows] Driver wants to link clang_rt.builtins.lib instead of clang_rt.builtins-x86_64.lib

[Meinersbur]

clang::ToolChain::getCompilerRT(...) searches for the location of the clang_rt.builtins library. It considers the paths with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON (clang_rt.builtins.lib) as well as LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF (clang_rt.builtins-x86_64.lib). When it does not find it, it falls back to clang_rt.builtins.lib (since #87866).

This might be fine for platforms such as Linux where LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON is the default, but breaks for platforms where it is off by default. In particular, under Windows the file is usually located under ${prefix}/lib/clang/${version}/lib/windows/clang_rt.builtins-x86_64.lib. If it is missing (e.g. in non-bootstrap builds), MSVC's toolchain also provides its own version e.g. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\lib\clang\18\lib\windows\clang_rt.builtins-x86_64.lib. With the change #87866 https://github.com/llvm/llvm-project/pull/87866/files#diff-58fde3c498133c1f93ff2df8cb10083eb6955637187074e16a87bd93cd1364f0R799-R805 the driver tells the linker to use clang_rt.builtins.lib which does not exist in any common configuration under Windows.

Also see #87866 (comment)

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Michael Kruse (Meinersbur)

`clang::ToolChain::getCompilerRT(...)` searches for the location of the `clang_rt.builtins` library. It considers the paths with `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON` (`clang_rt.builtins.lib`) as well as `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF` (`clang_rt.builtins-x86_64.lib`). When it does not find it, it falls back to `clang_rt.builtins.lib`.

This might be fine for platforms such as Linux where LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON is the default, but breaks for platforms where it is off by default. In particular, under Windows the file is usually located under ${prefix}/lib/clang/${version}/lib/windows/clang_rt.builtins-x86_64.lib. If it is missing (e.g. in non-bootstrap builds), MSVC's toolchain also provides its own version e.g. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\lib\clang\18\lib\windows\clang_rt.builtins-x86_64.lib. Since #87866 the driver tells the linker to use clang_rt.builtins.lib which does not exist in any default configuration under Windows.

Also see #87866 (comment)

[jhuber6]

Does anyone know what prevents us from enabling the per-target option on Windows? Otherwise I think the solution is to just update the code to search for the .<archname> variant. I guess the issue is that in general people don't like the driver needing to look through the file system.

[Meinersbur]

The option started opt-in for OSs starting with Linux in https://reviews.llvm.org/D107799, motivated by making it more similar to GNU convention. That convention doesn't apply to Windows, so there was never a motivation for it. I think the mistake is #81037 which applies the convention to ALL OSs, not only the ones for which LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON @MaskRay.

With changing the default to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON on all OSs would at least eliminate the disagreement between the driver's fallback name and the OSs default library name. But it is a risky change, I wouldn't dare to touch linking behaviour on all platforms at once.

For Windows, it also wouldn't immediately solve the problem. The nice thing is that the Visual Studio toolchain already comes with a clang_rt.builtins-x86_64.lib that is found by LINK.exe, but the driver has no idea about LINK.exe's search paths. In that sense the driver even trying to find which clang_rt.builtins library will use is a bad idea. It will never exactly match the search path of the linker. However, it will take some releases of Visual Studio until it instead ships with clang_rt.builtins.lib including the necessary adjustment to LINK.exe's default search path.