fail with 'Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR'

[aminya]

This issue is mirrored from aminya/project_options#200

@hihig2001 originally wrote:

I use visual studio 2022 17.4.4 with integrated cmake, and pre-installed vcpkg.
My cmake file is mostly similar with example file.
Difference is that I don't use run_vcpkg() functionality.
Instead, I register 'CMAKE_TOOL_CHAIN' using CMakePresets.json, just like visual studio's official manual.

I'm not so sure about that it is appropriate to report here or 'WindowsToolchain' cause it is dependency not 'project_option' itself.
but I thought that it is something worth to report.

1> Command line: "C:\WINDOWS\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake" -DCMAKE_C_COMPILER:STRING="cl" -DCMAKE_CXX_COMPILER:STRING="cl" -DCMAKE_BUILD_TYPE:STRING="Debug" -DFEATURE_UNIT_TESTS:STRING="ON" -DCMAKE_INSTALL_PREFIX:PATH="E:/work/Knuckles/Game/out/install/windows-msvc-debug-soft-mode"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "E:\work\Knuckles\Game" 2>&1"
1> Working directory: E:/work/Knuckles/Game/out/build/windows-msvc-debug-soft-mode
1> [CMake] CMake Warning (dev) at C:/Program Files/Microsoft Visual Studio/2022/Professional/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.24/Modules/FetchContent.cmake:1264 (message):
1> [CMake]   The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
1> [CMake]   not set.  The policy's OLD behavior will be used.  When using a URL
1> [CMake]   download, the timestamps of extracted files should preferably be that of
1> [CMake]   the time of extraction, otherwise code that depends on the extracted
1> [CMake]   contents might not be rebuilt if the URL changes.  The OLD behavior
1> [CMake]   preserves the timestamps from the archive instead, but this is usually not
1> [CMake]   what you want.  Update your project to the NEW behavior or specify the
1> [CMake]   DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
1> [CMake]   robustness issue.
1> [CMake] Call Stack (most recent call first):
1> [CMake]   CMakeLists.txt:24 (FetchContent_Declare)
1> [CMake] This warning is for project developers.  Use -Wno-dev to suppress it.
1> [CMake] 
1> [CMake] -- Using Windows Windows toolchain
1> [CMake] CMake Error at out/build/windows-msvc-debug-soft-mode/_deps/_msvc_toolchain-src/Windows.MSVC.toolchain.cmake:169 (message):
1> [CMake]   Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR
1> [CMake] Call Stack (most recent call first):
1> [CMake]   out/build/windows-msvc-debug-soft-mode/_deps/_project_options-src/src/VCEnvironment.cmake:72 (include)
1> [CMake]   out/build/windows-msvc-debug-soft-mode/_deps/_project_options-src/src/Index.cmake:34 (msvc_toolchain)
1> [CMake]   out/build/windows-msvc-debug-soft-mode/_deps/_project_options-src/CMakeLists.txt:3 (include)
1> [CMake] -- Configuring incomplete, errors occurred!
1> 'C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake" -DCMAKE_C_COMPILER:STRING="cl" -DCMAKE_CXX_COMPILER:STRING="cl" -DCMAKE_BUILD_TYPE:STRING="Debug" -DFEATURE_UNIT_TESTS:STRING="ON" -DCMAKE_INSTALL_PREFIX:PATH="E:/work/Knuckles/Game/out/install/windows-msvc-debug-soft-mode"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "E:\work\Knuckles\Game" 2>&1"' execution failed with error: ''C:\WINDOWS\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake" -DCMAKE_C_COMPILER:STRING="cl" -DCMAKE_CXX_COMPILER:STRING="cl" -DCMAKE_BUILD_TYPE:STRING="Debug" -DFEATURE_UNIT_TESTS:STRING="ON" -DCMAKE_INSTALL_PREFIX:PATH="E:/work/Knuckles/Game/out/install/windows-msvc-debug-soft-mode"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "E:\work\Knuckles\Game" 2>&1"' returned with exit code: 1'.

[aminya]

I think by using the detect_architecture function of project_options this issue can be fixed.

https://github.com/aminya/project_options/blob/0aae24f7ac01d262055079d6ddca7070506082af/src/Utilities.cmake#L147-L207

[MarkSchofield]

Perhaps just defaulting CMAKE_SYSTEM_PROCESSOR to CMAKE_HOST_SYSTEM_PROCESSOR would suffice?

[MarkSchofield]

Oh... I try and default CMAKE_SYSTEM_PROCESS to CMAKE_HOST_SYSTEM_PROCESSOR, here:

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_HOST_SYSTEM_PROCESSOR})
endif()

[hihig2001]

I downloaded last 'WindowsToolchain' which was 'project_option' dependent, back when 'project option' works.
and check some diff with current and I found that what has changed.

it was

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR x64)
endif()

so I manually changed newer version(v0.5.1)'s ${CMAKE_HOST_SYSTEM_PROCESSOR} with x64 to see if it works after.
and it worked!

I don't know well enough on cmake, but it seems that relying on ${CMAKE_HOST_SYSTEM_PROCESSOR} is not enough?

[ClausKlein]

see CMAKE_SYSTEM_PROCESSOR

[hihig2001]

As you see -DCMAKE_TOOLCHAIN_FILE:FILEPATH="C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake"
toolchain file has setted with vcpkg.
Is it mean that there are order dependency problem?
Since I have no knowledge wit when cmake_toolchain_file do works, I don't have an answer for that.

[ClausKlein]

so I manually changed newer version(v0.5.1)'s ${CMAKE_HOST_SYSTEM_PROCESSOR} with x64 to see if it works after. And it worked!

I don't know well enough on cmake, but it seems that relying on ${CMAKE_HOST_SYSTEM_PROCESSOR} is not enough?

IMHO: You are cross compiling!
" When cross-compiling, a CMAKE_TOOLCHAIN_FILE should set the CMAKE_SYSTEM_PROCESSOR variable to match target architecture that it specifies (via CMAKE_LANG_COMPILER and perhaps CMAKE_LANG_COMPILER_TARGET). "

[hihig2001]

Please let me know if if I misunderstand something.

Since I have set CMAKE_TOOLCHAIN_FILE with vcpkg.cmake, vcpkg.cmake' will set CMAKE_HOST_SYSTEM_PROCESSOR and CMAKE_SYSTEM_PROCESSOR eventually.

It means that WindowsToolchain must be executed after CMAKE_SYSTEM_PROCESSOR has resolved, which means that CMAKE_TOOLCHAIN_FILE must be executed before WindowsToolchain is executed.

But I have no idea when cmake runs CMAKE_TOOLCHAIN_FILE.
I followed canonical example of cross compiling in 'VS2022 cmake project' and 'project_option'.
Should I do force something?

[ClausKlein]

IMHO: If you are working with ninja and MS cc, this is the right toolchain.cmake
It should set all this cmake variables right.
If not, help them to do it: cmake -D CMAKE_HOST_SYSTEM_PROCESSOR=x86 ...

If it works, I do not know, if have never tried to build a win 32 BIT program with it.

[MarkSchofield]

Since WindowsToolchain is a toolchain, it's supposed to set CMAKE_SYSTEM_PROCESSOR. It was originally defaulting to x64, but that's wrong for a couple of reasons:

• Error selecting MSVC toolchain #41 demonstrated that x64 wasn't right. Since it needs to align to CMAKE_HOST_SYSTEM_PROCESSOR, and CMAKE_HOST_SYSTEM_PROCESSOR defaults to the value of the PROCESSOR_ARCHITECTURE environment variable on Windows (as per the CMAKE_HOST_SYSTEM_PROCESSOR documentation), and that's AMD64 for 64-bit OS's.
• The CMAKE_SYSTEM_PROCESSOR documentation says that its value should default to the value of CMAKE_HOST_SYSTEM_PROCESSOR when not-cross-compiling. And that should be the default.

So the fix for #41 (#42) changed the default of CMAKE_SYSTEM_PROCESSOR to be CMAKE_HOST_SYSTEM_PROCESSOR. Which seems to be the right thing to do. And on my machine, that works. If I don't set a CMAKE_SYSTEM_PROCESSOR value in, say, my CMakePresets.json this logic kicks in:

if(NOT CMAKE_SYSTEM_PROCESSOR)
    set(CMAKE_SYSTEM_PROCESSOR ${CMAKE_HOST_SYSTEM_PROCESSOR})
endif()

And CMAKE_SYSTEM_PROCESSOR is defaulted to CMAKE_HOST_SYSTEM_PROCESSOR. And everything works for me.

The error message from OP, contains the text:

Unable identify compiler architecture for CMAKE_SYSTEM_PROCESSOR

That's written by this code which shows that the value of CMAKE_SYSTEM_PROCESSOR is written at the end of the message, so in this case, it's empty! The only way I can see that being the case is if CMAKE_HOST_SYSTEM_PROCESSOR is empty - which I don't see on my machine, but I am using the latest CMake (3.25.2 at the moment).

What version of CMake are you using? Any idea why CMAKE_HOST_SYSTEM_PROCESSOR would be empty? I could check for an empty CMAKE_HOST_SYSTEM_PROCESSOR, and default it to $ENV{PROCESSOR_ARCHITECTURE}, but that seems to be overly defensive until we've understood why CMAKE_HOST_SYSTEM_PROCESSOR is empty in the first place.

[MarkSchofield]

The fact that you're specifying the vcpkg.cmake as your CMAKE_TOOLCHAIN_FILE means that WindowsToolchain isn't your CMAKE_TOOLCHAIN_FILE - you must be include'ing it later...? I haven't tried that; I'll perhaps try and pull together a repro of that when I get a chance.

TBH, even though the VCPkg documentation says to specify vcpkg.cmake as the CMAKE_TOOLCHAIN_FILE, it doesn't seem to fulfil the role of a toolchain file - i.e. determining the location of the necessary compiler/utility paths. Infact, microsoft/vcpkg#8163 offers a similar sentiment.

[MarkSchofield]

OK, I tried using WindowsToolchain and VCPkg, and whilst it was a bit painful - I'll file a separate issue to have that conversation - I can't reproduce the CMAKE_HOST_SYSTEM_PROCESSOR-being-blank problem (that I'm currently assuming this is).

I think that the best way to track this down would be to use --trace to find - presumably - where CMAKE_HOST_SYSTEM_PROCESSOR is being cleared. If I configure the 'example' folder with --trace, then I see CMAKE_HOST_SYSTEM_PROCESSOR being set almost immediately, followed by the toolchain being processed. Here's the start of the file:

WindowsToolchain/example/CMakeLists.txt(4):  cmake_minimum_required(VERSION 3.20 )
WindowsToolchain/example/CMakeLists.txt(6):  project(WindowsToolchainExample )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(1):  set(CMAKE_HOST_SYSTEM Windows-10.0.22621 )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(2):  set(CMAKE_HOST_SYSTEM_NAME Windows )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(3):  set(CMAKE_HOST_SYSTEM_VERSION 10.0.22621 )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(4):  set(CMAKE_HOST_SYSTEM_PROCESSOR AMD64 )
WindowsToolchain/example/__output/windows-msvc-blank/CMakeFiles/3.25.2/CMakeSystem.cmake(6):  include(WindowsToolchain/Windows.MSVC.toolchain.cmake )
WindowsToolchain/Windows.MSVC.toolchain.cmake(60):  cmake_minimum_required(VERSION 3.20 )

So CMake is setting:

CMAKE_HOST_SYSTEM
CMAKE_HOST_SYSTEM_NAME
CMAKE_HOST_SYSTEM_VERSION
CMAKE_HOST_SYSTEM_PROCESSOR

And then processing the toolchain. I'm assuming that because you're using the VCPkg as your toolchain, then something must be clearing CMAKE_HOST_SYSTEM_PROCESSOR before it gets to WindowsToolchain..? The --trace output should list where that's happening, and we can figure out what can be done about it. Reply back with details..?

[aminya]

Is there a minimal reproduction of this issue? I use vcpkg every day without problems. Is the difference in adding the toolchain in CMakePresets instead of using the provided run_vcpkg function?

[MarkSchofield]

I'm unable to reproduce this. If anyone can reproduce it, and can share steps, or is comfortable sharing their --trace output, then that should hopefully provide some actionable information.

[Nosenzor]

Is there a minimal reproduction of this issue? I use vcpkg every day without problems. Is the difference in adding the toolchain in CMakePresets instead of using the provided run_vcpkg function?

Try to use lukka's run_vcpkg with a simple project. It fails for this reason on windows runners. (Reproduced with 0.30)