Windows Clang with ninja backend not supported

[jon-turney]

Trying to run test suite with clang compiler and ninja backend on Windows has various test failures (See this appveyor CI run)

See also #4105 (comment), #3670 (comment)

[jon-turney]

Analysing this failure a bit:

test_templates (__main__.AllPlatformTests) ...
[...]
[3/5] Linking target subprojects/notzlib/libnotzlib.dll.
LINK : warning LNK4044: unrecognized option '/-no-undefined'; ignored
LINK : warning LNK4044: unrecognized option '/-as-needed'; ignored
LINK : warning LNK4044: unrecognized option '/-start-group'; ignored
LINK : warning LNK4044: unrecognized option '/-out-implib=subprojects\notzlib\libnotzlib.dll.a'; ignored
LINK : warning LNK4044: unrecognized option '/-end-group'; ignored
   Creating library subprojects/notzlib/libnotzlib.lib and object subprojects/notzlib/libnotzlib.exp
[4/5] Generating symbol file subprojects/notzlib/subprojects@notzlib@@notzlib@sha/libnotzlib.dll.symbols.
[5/5] Linking target test_not_zlib.exe.
FAILED: test_not_zlib.exe
clang @test_not_zlib.exe.rsp
clang.exe: error: no such file or directory: 'subprojects\notzlib\libnotzlib.dll.a'

Clang appears to be using MSVC's LINK. So it seems we need to handle the linker option style varing depending on the host machine.

I thought this might be fixable with -fuse-ld=ld.lld and always using ld-style options, but that seems to have other problems.

[mstorsjo]

Clang appears to be using MSVC's LINK. So it seems we need to handle the linker option style varing depending on the host machine.

I thought this might be fixable with -fuse-ld=ld.lld and always using ld-style options, but that seems to have other problems.

I don't think you can force it to use the unix style linker when using linking via the clang msvc driver; the clang msvc mode driver always passes linker options in link.exe form. So if you add -fuse-ld=lld, it'll invoke lld-link with link.exe style options still.

This confusion is probably easiest avoided by using the same codepaths for clang in msvc mode as with regular msvc, and use the clang-cl frontend for it.

[jon-turney]

This confusion is probably easiest avoided by using the same codepaths for clang in msvc mode as with regular msvc, and use the clang-cl frontend for it.

Yeah. Of course, when I wrote this I was assuming that clang-cl just worked ("it's cl compatible!"), but doesn't for various other reasons. I'll look at that first.

I don't think you can force it to use the unix style linker when using linking via the clang msvc driver; the clang msvc mode driver always passes linker options in link.exe form. So if you add -fuse-ld=lld, it'll invoke lld-link with link.exe style options still.

Is clang-cl what you mean by the 'msvc mode driver'? I see this behaviour with clang as well.

Unfortunately, at the moment, meson assumes a 1:1 correspondence between compiler and linker argument types, so getting this to work is going to involve some effort.

And given what you wrote in #3670, I guess we could get either behaviour on Windows, depending on how clang was built (MSVC mode or MinGW mode)?

[jon-turney]

This confusion is probably easiest avoided by using the same codepaths for clang in msvc mode as with regular msvc, and use the clang-cl frontend for it.

Yeah. Of course, when I wrote this I was assuming that clang-cl just worked ("it's cl compatible!"), but doesn't for various other reasons. I'll look at that first.

See PR #4250

[mstorsjo]

I don't think you can force it to use the unix style linker when using linking via the clang msvc driver; the clang msvc mode driver always passes linker options in link.exe form. So if you add -fuse-ld=lld, it'll invoke lld-link with link.exe style options still.

Is clang-cl what you mean by the 'msvc mode driver'? I see this behaviour with clang as well.

You hit the same "msvc mode driver" both if you run clang-cl and clang -target <arch>-windows-msvc. The difference between the two just is how it interprets the incoming arguments at this point; from that point onwards (how it compiles things, how it invokes the linker) is identical between the two.

Unfortunately, at the moment, meson assumes a 1:1 correspondence between compiler and linker argument types, so getting this to work is going to involve some effort.

And given what you wrote in #3670, I guess we could get either behaviour on Windows, depending on how clang was built (MSVC mode or MinGW mode)?

Exactly - what the default triple of your clang is, if nothing is specified, depends on the configuration. (clang -v prints that.) Parsing that feels a bit messy, but I'm not sure if there are many other options either. (I haven't followed the full context of this issue here yet though, just thought I'd pitch in with my 2 cents on these details.)

[barcharcraz]

another problem is that when building with clang.exe on windows (with default target x86_64-pc-windows-msvc) clang does not pass the winlibs linker args

[barcharcraz]

As an alternative to parsing clang-v one could compile a test library and actually check what abi is being used. See #2560 (comment)

[XVilka]

So, was this one fixed by #4250 ?

[jon-turney]

Only partially.

Using clang-cl should work, but since we prefer clang to clang-cl when detecting compilers, that will only happen if you explicitly specify clang-cl (either via CC/CXX or a cross-file)

Fixing clang is more work (per #4232 (comment)).

[jon-turney]

since we prefer clang to clang-cl when detecting compilers

Hmm... this is possibly a mistake, or at least not very helpful with the current state of things (we have a fixed search order ['cl', 'cc', 'gcc', 'clang', 'clang-cl'], where I just added clang-cl to the end as part of #4250.

(see also #4498)

[jon-turney]

that will only happen if you explicitly specify clang-cl (either via CC/CXX or a cross-file)

Oh. Or you use LLVM 6, which installs clang-cl with the name cl.

“A moving target is easier to miss"

[jon-turney]

Still grinding away at this. #4573 adds support for clang with the *-windows-gnu target (another thing I was assuming would 'just work' 😞 )

[RoyiAvital]

@jon-turney , You wrote:

Using clang-cl should work, but since we prefer clang to clang-cl when detecting compilers, that will only happen if you explicitly specify clang-cl (either via CC/CXX or a cross-file)

So I should define clang.exe as Compiler on Windows?
The problem is the default configuration doesn't define the equivalent of /MT or /MD.
How could one set that when using clang (Not clang-cl) on Windows?

[jon-turney]

Only CC=clang-cl works with meson at the moment. This bug is still open because using CC=clang (= having clang.exe in the PATH) doesn't work .

[RoyiAvital]

The problem is with clang-cl it is not possible to push -Xclang -<ClangFlag>. See my issue with -fopenmp.

[XVilka]

Were there any updates regarding this?

[jon-turney]

Progress is slow, I'm afraid. I believe that PR #5681 should remove the architectural limitation which is the major blocking issue here.

[dcbaker]

I'm planning on working on getting windows sorted in that PR today.

[XVilka]

So the #5681 is merged now, is there anything else that prevents this from getting this fixed?

[dcbaker]

I'll go ahead and close this, we can reopen or open new bugs if there's more work to do.