Incorrect subsystem on windows with VS2022 #126
Comments
|
Note that a solution might just be to always define |
|
This is weird, the subsystem should be selected via ...also the CI should actually fail in that case... |
|
Hmm, I just tried the process from scratch and it works here. Can you give a bit more context?
|
|
For instance on my system: cmake version 3.27.1 Microsoft Visual Studio Community 2022 (64-bit) - Current |
|
Also, when I open Visual Studio (via
(none of the samples under ...looking at the generated .vcxproj files, all targets are set to SubSystem Windows (which is correct but seems to be different on your side):
Something must be wrong about the cmake generation step I think... |
|
Ok redoing it from scratch: All the samples fail, ex: first 2 errors: |
|
PS C:\scratch\sokol-samples> cmake --version => Oh I see, it's not the latest one, I guess I can upgrade to 3.27, who knows maybe that will fix, I'll keep you updated. Microsoft Visual Studio Community 2022 (64-bit) - Current
=> yours is showing stack reserve size, while mine shows nothing there. I'll check with the latest CMake. (edit: done) By the way, I forgot to thank you for the prompt reply! |
|
After comparing your file and mine, I see that the main difference is this, you have: and I have: That's probably the issue, right? |
Wow yeah, let me check how this is detected... |
|
Hmm, still weird. When FIPS_PLATFORM isn't set it means it's not including this windows.cmake file here: https://github.com/floooh/fips/blob/master/cmake-toolchains/windows.cmake That should happen here when ...but that is definitely set because the message Your Visual Studio seems to be a bit more recent... currently updating. One more thing, are you building on PowerShell? If yes can you try on a "vanilla" cmd.exe (e.g. also not a "Visual Studio Command Prompt"). It should still work, but these are the only other differences I can think of. I'll continue investigating tomorrow, it's pretty late now :) |
|
Btw, can you also check this project: https://github.com/floooh/pacman.c This isn't using my fips cmake wrapper but a regular CMakeLists.txt instead. Build instructions are in the readme. If this also fails (which I don't expect), then it would be some incompatibility between cmake and the latest VS (unlikely though). |
|
Hmm, updated to VS 17.7.5 and it's still working here, both on cmd.exe and in Powershell. Running out of ideas... |
|
Ok, one last thing before I hit the sack: Can you add a couple of debug-messages to the fips directory that's been checked out next to sokol-samples: ...in if (NOT CMAKE_TOOLCHAIN_FILE)
message("######### in NOT CMAKE_TOOLCHAIN_FILE")
if (FIPS_HOST_WINDOWS)
message("######### including windows.cmake")
include(${FIPS_ROOT_DIR}/cmake-toolchains/windows.cmake)
elseif (FIPS_HOST_OSX)
message("######### including osx.cmake")
include(${FIPS_ROOT_DIR}/cmake-toolchains/osx.cmake)
else()
message("######### including linux.cmake")
include(${FIPS_ROOT_DIR}/cmake-toolchains/linux.cmake)
endif()
endif()... then run I basically want to check if windows.cmake is actually included. |
|
PS: do you have an environment variable |
|
Anyway logging out now :) |
|
Hi, just letting you know that I will check everything tomorrow, I just had a full day trip. |
|
Pacman works fine.
Bingo! I edited the fips.cmake to remove the toolchain check, and then it compiles fine on windows. I also tried emscripten a few days ago and that worked fine too. |
But this is entirely correct. What's concerning is that there is no When the windows.cmake file is included, it should work because this should set the correct subsystems, otherwise such problems are expected. |
Just following the basic guide:
=>
error LNK2019: unresolved external symbol main referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)The reason is that the
mainhijack is not working, because it's being overridden by the project subsystem, which is set to Console (instead of NotSet).If I change the SubSystem to Windows or NotSet then it works, but it would be nice if the tool could do it automatically, of if the hijack could override that setting.
The text was updated successfully, but these errors were encountered: