Cmake test program triggers Windows Defender

MSYS2, RTools etc.

I get a (false positive) threat alert from Windows Defender when running cmake from MSYS2. The point at which it fails is very simple stuff from CheckFloatingPointFormat.cmake. The script is basically compiling CheckFloatingPointFormat.c, and then grepping it to check if it finds ABCDEFGH in the binary. Windows Defender does not like the exe, for whatever reasons, maybe some viruses use the same logic to investigate their victims.

Since we do not need an executable, a static library is fine, so I add a line and Windows Defender is silent again:


I’ll make the respective PR.

What I am wondering, though: The little program is used to detect if the system is little endian or big endian at compile time. But this refers to the host, not to the target (e.g., when crosscompiling). Shouldn’t such a test be made at runtime?

Thanks. Merged. Does no harm in this case. Sooner or later Defender probably blocks building the system :frowning:

No. try_compile uses the cross compilers. That is why the code is not executed but instead, the binary is scanned. At least, that is my understanding …

I see. Makes sense. I’ve got two more patches, these refer to cmake’s own macros:

(1) In Ports.cmake: Instead of cmake’s deprecated macro


we could just ask if(CMAKE_C_BYTE_ORDER STREQUAL “BIG_ENDIAN”). I’ll submit another PR for this, that also handles the case in which CMAKE_C_BYTE_ORDER is undefined.

(2) In Config.cmake, there are some calls to cmake’s own check_type_size, these are equally affected. I added another SET(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY). I’ll add a PR, but I will also report it upstream to the cmake people. If you think the PR is unnecessary because it is cmake’s business, just reject.

Windows Defender will still issue a lot of warnings (I guess there are a few more try_compiles), but they don’t block the build anymore.