C5105 and other compiler warnings when building with Github Actions / WinSDK 10.0.17763.0

Viewed 968

A couple of days ago I have started to migrate my CMake-based C++ library project from Travis CI to GitHub Actions. I immediately ran into trouble with the windows-latest runner (link to runner specs). After many wasted hours I tracked down the issue to the Windows SDK that CMake selects when it generates the build system.

On a local VM where I tried to replicate the runner environment CMake always selects the SDK version 10.0.18362.0, because no other SDK is installed on that system. On the runner system, though, there seem to be several SDKs installed (cf. the runner specs), and CMake by default selects SDK version 10.0.17763.0.

The actual problem: With 10.0.17763.0 selected, as soon as the first file is being compiled the compiler starts spewing out C5105 warnings like the following (line breaks added by me for better readability):

C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt_search.h(188,5):
  warning C5105: macro expansion producing 'defined' has undefined behavior
 [D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]

C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\stdlib.h(79,5):
  warning C5105: macro expansion producing 'defined' has undefined behavior
 [D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]

[...]

Eventually there are also errors which cause the build to fail. The first of these errors is this:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(487,17):
  error C2059: syntax error: '/'
  [D:\a\libsgfcplusplus\libsgfcplusplus\build\src\libsgfcplusplus_shared_objects.vcxproj]

When I force CMake to use a different SDK, by setting CMAKE_SYSTEM_VERSION to 10.0.18362.0, all problems go away and the build works fine.

Before I go down that road of forcing CMake to do something it doesn't want to do, I wanted to ask for advice if someone can recommend a better approach?

Also of interest would be if someone could explain what's actually going on here? How is it possible that MSVC has problems parsing Microsoft's own system header files when using one SDK version, and no problem at all when using another SDK version? Link to a build log in case someone is interested, but this might go away soon when I delete the branch.

1 Answers

In the meantime I managed to reproduce the problem on my local VM by installing the component "Windows 10 SDK (10.0.17763.0)" in the Visual Studio Installer. On the VM CMake still defaults to 10.0.18362.0, but when I force it to use 10.0.17763.0 like this

cd build
cmake -DCMAKE_SYSTEM_VERSION="10.0.17763.0" ..

then I get the same build failure as on the Github Actions runner. At least I can now say that it's not the Github Actions runner that is at fault.

On the other hand I also can't see how my project should be the culprit. I certainly don't do anything special that should make the project build with one Windows SDK, but not with the other.

Lacking the time (and the will) to further investigate the issue, for the moment I decided to follow the path of least resistance and am now building with these lines in the project's build.yml:

cd build
cmake -DCMAKE_SYSTEM_VERSION="10.0.18362.0" ..
cmake --build . --config Release
Related