search

mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.41k stars 1.55k forks source link

Windows subsystem option not recognized when using LLVM #8799

Open kotx opened 3 years ago

kotx commented 3 years ago

Describe the bug I installed llvm via scoop and tried to compile a hello world program (created by meson init). Worked with gcc, so I thought this was an llvm issue. Not sure. I have Visual Studio 2019 installed with the C++ toolchains. (Using ninja backend though)

When I run meson compile -C build (after meson build):

"clang++"  -Wl,/MACHINE:X64 -Wl,/OUT:x.exe x.exe.p/src_main.cpp.obj "-Wl,/nologo" "-Wl,/release" "-Wl,/nologo" "-Wl,/DEBUG" "-Wl,/PDB:x.pdb" "-Wl,--subsystem,windows" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32"
LINK : warning LNK4044: unrecognized option '/-subsystem'; ignored
LINK : fatal error LNK1181: cannot open input file 'windows.obj'
clang++: error: linker command failed with exit code 1181 (use -v to see invocation)

To Reproduce

executable('x', sources,
  ...
  win_subsystem: 'windows'
)

However, removing win_subsystem altogether produces the above error but with console.obj instead of windows.obj. The option /-subsystem still is present and not recognized.

Expected behavior An executable with windows_subsystem of windows is compiled.

system parameters

kotx commented 3 years ago

Also, this might not be related but I can't specify c++20, I must specify c++2a for it to configure successfully. However, my clang++ version is 12.0.0.

meson.build:1:0: ERROR: Value "c++20" (of type "string") for combo option "C++ language standard to use" is not one of the choices. Possible choices are (as string): "none", "c++98", "c++03", "c++11", "c++14", "c++17", "c++1z", "c++2a", "gnu++11", "gnu++14", "gnu++17", "gnu++1z", "gnu++2a".
kotx commented 3 years ago

This problem does not occur on my other machine that only has VS2019 and meson installed.

dcbaker commented 3 years ago

It appears you're using vanilla clang, is that your intention? I'm not sure what the status of vanilla clang (as opposed to clang-cl) with link or lld-link is.

kotx commented 3 years ago

It appears you're using vanilla clang, is that your intention? I'm not sure what the status of vanilla clang (as opposed to clang-cl) with link or lld-link is.

I'm not sure, I'm not running in a VS Developer command prompt though, so it shouldn't be in PATH (I think..)

dcbaker commented 3 years ago

Can you check that you're getting the same compiler for both of them? I think meson is selecting msvc on one of your machines, and clang on the other, and that's where the problems are coming from.

You can try (assuming you're using cmd.exe):

set CC=cl
set CXX=cl
meson setup $builddir --wipe

and see if that helps.

kotx commented 3 years ago

Can you check that you're getting the same compiler for both of them? I think meson is selecting msvc on one of your machines, and clang on the other, and that's where the problems are coming from.

You can try (assuming you're using cmd.exe):

set CC=cl
set CXX=cl
meson setup $builddir --wipe

and see if that helps.

It can't find cl.exe: Running "cl /?" gave "[WinError 2] The system cannot find the file specified" Using it from the VS Dev prompt (or running vcvarsall.bat first) works, however I must specify c++latest instead of c++20 since that's how msvc does versions AFAIK. That might be less portable

dcbaker commented 3 years ago

It's rather unfortunate that gcc and clang use versions like c++1x and c++2a and msvc just uses c++latest. I'm not really sure what we can do about that though.

kotx commented 3 years ago

How do I make meson/ninja not use msvc then? Is that possible?

e820 commented 3 years ago

Seems like the linker detection is broken yet again? https://github.com/mesonbuild/meson/blob/a9959a385990bb9760cfdb5fda9a6bc6fb7725fe/mesonbuild/linkers.py#L1183-L1204

If this build is actually using clang to invoke link then -Wl,--subsystem,windows should never be passed. The same logic applies to lld-link too, yet somehow it seems meson thinks the linker is a gnu-ish linker. https://github.com/mesonbuild/meson/blob/a9959a385990bb9760cfdb5fda9a6bc6fb7725fe/mesonbuild/linkers.py#L695-L705

Invoking lld-link through clang should have been working fine ever since the commits to fix the detection landed upstream. I originally introduced them to build EFI apps with clang + lld-link and it works fine on my end.