On Fri Nov 25 16:58:02 2022 +0000, Jacek Caban wrote:
I tested it with: ``` $ echo _MSC_VER | clang -E -target x86_64-windows -fuse-ld=bfd - # 1 "<stdin>" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 341 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "<stdin>" 2 _MSC_VER $ echo _MSC_VER | clang -E -target x86_64-windows -fuse-ld=lld - # 1 "<stdin>" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 355 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "<stdin>" 2 1920 ``` Trying a few more cases, it seems that the problem happens when `-fuse-ld` is bfd*, any other (possibly invalid) values work fine. Thanks!
This led me to this find: https://github.com/llvm/llvm-project/blob/llvmorg-15.0.0/clang/lib/Driver/Dr... ``` if (Args.getLastArgValue(options::OPT_fuse_ld_EQ) .startswith_insensitive("bfd")) TC = std::make_unique<toolchains::CrossWindowsToolChain >( *this, Target, Args); else TC = std::make_unique<toolchains::MSVCToolChain>(*this, Target, Args); ``` I'm not quite sure what the `CrossWindowsToolChain` is - I think it might be something used for the "windows-itanium" case (which is a third windows target in addition to mingw and msvc - it's a setup kinda inbetween msvc and mingw, used in some proprietary setups). With that in mind, I guess it's better to override `-fuse-ld=lld` so it actually picks the right MSVC toolchain, rather than trying to coerce `CrossWindowsToolChain` to behave as expected. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1549#note_17480