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)

[mstorsjo]

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.

The status of llvm-rc is that it's not ready as a drop-in replacement for rc.exe in general. llvm-rc in itself doesn't run the preprocessor like rc.exe or windres do. llvm-mingw (https://github.com/mstorsjo/llvm-mingw) uses llvm-rc to implement a windres style frontend, with a shellscript frontend that first invokes the preprocessor and then passes the output from that to llvm-rc.

[XVilka]

@mstorsjo are there any bugs in llvm bug tracker for llvm-rc to follow?

[mstorsjo]

@XVilka I'm not aware of any, I think the known remaining issues are mostly listed in people's personal todo lists unfortunately. The issues I'm aware of is lacking built-in preprocessor, and the MENUEX resource type.

[XVilka]

@mstorsjo seems preprocessing already landed in llvm-rc: https://reviews.llvm.org/D46579

[mstorsjo]

@mstorsjo seems preprocessing already landed in llvm-rc: https://reviews.llvm.org/D46579

No, that's a different thing. (I'm the one who implemented that.) That patch is a requirement to make llvm-rc work when the preprocessor has been executed outside of llvm-rc, when headers with C declarations have been included.

[XVilka]

https://bugs.llvm.org/show_bug.cgi?id=40108 - I created a bug, since there wasn't one

[cdecompilador]

No solutions on this??

[jon-turney]

No solutions on this??

You should be able to explicitly specify the resource compiler to use as per points 1 and 2 in https://mesonbuild.com/Windows-module.html (point 1 should say "cross or native" file or "machine file" or something...)

If automatic selection (point 3) isn't working, can you say what toolchain you are using, and what resource compiler tool you have that you are expecting meson to automatically find?

[mstorsjo]

Is this a case when msvc tools aren’t in PATH, but only clang-cl (and clang-cl can locate the sdk and msvc installation on its own) - thus no rc.exe can be found?