Meson can't find the resource compiler when using clang in MSVC ABI mode

[barcharcraz]

If you set the compiler to clang on windows, using the clang.exe build that operates using the platform ABI then meson won't find the resource compiler. This arises from the fact that the windows module only looks for 'rc.exe' if the compiler id is msvc

[jon-turney]

If you set the compiler to clang on windows [...] meson won't find the resource compiler. This arises from the fact that the windows module only looks for 'rc.exe' if the compiler id is msvc

Yeah, this is not working as desired.

Do you mean it should use MSVS's rc.exe? This might not be installed (definitely not if this is a cross-compilation, so I suppose we need to look for both rc and windres)

There also seems to be a llvm-rc, but I'm not sure what the status of that is.

using the clang.exe build that operates using the platform ABI

Does this mean "a Windows clang", or something else?

[barcharcraz]

It means clang that generates C++ code with the Microsoft abi (as opposed to the itanium abi). The installer from llvm.org does this. And I do mean he rc compiler and it is installed and in the path. The problem is in windows.py line 52

…

On Fri, Aug 31, 2018 at 3:57 PM Jon Turney ***@***.***> wrote: If you set the compiler to clang on windows [...] meson won't find the resource compiler. This arises from the fact that the windows module only looks for 'rc.exe' if the compiler id is msvc Yeah, this is not working as desired. Do you mean it should use MSVS's rc.exe? This might not be installed (definitely not if this is a cross-compilations, so I suppose we need to look for both rc and windres) There also seems to be a llvm-rc, but I'm not sure what the status of that is. using the clang.exe build that operates using the platform ABI Does this mean "a Windows clang", or something else? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPnvUsuonvoX4mIWJiWJ2g7Kvq2gyt_ks5uWZUpgaJpZM4WURrW> .

[barcharcraz]

perhaps the rc executable should be exposed for cross files. It's actually not unreasonable to treat every build on windows as a cross build.

[jon-turney]

And I do mean the rc compiler and it is installed and in the path

This is a bold claim to make for all possible meson users 😁

I've created a PR which makes things a bit more flexible, but this probably still needs to do something definite in the clang case.

I can't seem to get any CI tests to run successfully with Windows clang, as it seems to want to use lld-link, but we are emitting gcc-style linker options.

Are you using the ninja or VS backend?

[barcharcraz]

ninja.

I'll try and make a repro test case next time I find myself on windows

[jon-turney]

ninja.

Thanks.

Do you get 'unrecognized option; ignored' warnings as seen in this appveyor CI run, using jon-turney@4cc3236 ?

[barcharcraz]

I get those too, I guess those need to get fixed first.

[barcharcraz]

OK so I think I figured it out. If you use "clang++" or "clang" as the compiler then things don't really work because they don't understand how to link to the C library. Clang-cl does and accepts /MDd (or -MDd). Meson screws the pooch here because it passes "/-MDd"

[barcharcraz]

Here is a project that repros the problem when compiled on windows with the included cross file.
testproj.zip

[barcharcraz]

that said your commit above fixes the particular issue with the cross file.

I do get those warnings with clang-cl, and I get a compilation failure with regular clang. (although the second case may be on glib)