Fix build using newest gcc(10/11) with new msys/mingw toolchains
Issue
Build with newest msys/mingw toolchain using gcc/g++ compiler fails because it confuses GNU and MSVC compilers.
Option _WIN32 is defined now and so cannot be used anymore to detect gcc as opposed to msvc starting from gcc v.10.
Details
The excerpts of prepro-defines declared for gcc now ...
$ gcc --version
gcc.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 11.2.0
# 64-bit:
$ gcc -m64 -dM -E - < /dev/null | grep -E 'WIN32|GNUC__|WIN64|__VERSION__' | sort -d
#define __GNUC__ 11
#define __VERSION__ "11.2.0"
#define WIN32 1
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN64 1
#define _WIN64 1
#define __WIN64 1
#define __WIN64__ 1
# 32-bit:
$ gcc -m32 -dM -E - < /dev/null | grep -E 'WIN32|GNUC__|WIN64|__VERSION__' | sort -d
#define __GNUC__ 11
#define __VERSION__ "11.2.0"
#define WIN32 1
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
For windows platform (WIN32 or _WIN32 set), the compilers can be detected using following preprocessor defines:
| compiler | #if statement |
|---|---|
| gcc or clang | defined(__GNUC__) |
| gcc | (defined(__GNUC__) && !defined(__clang__)) |
| clang | defined(__clang__) |
| msvc | defined(_MSC_VER) |
Or using related BOOST_COMP_* defines since hyperscan already includes boost.
Fix
Proposed PR fixes the issue with misdetected (msvc) compiler using _MSC_VER instead of _WIN32 in minimalist approach, so one is able to build hyperscan with modern gcc compilers hereafter.
Note
The PR including #332 at the moment, I could rebase the branch to HEAD without 8306d2f if desired.
Toolchain and platform details
$ cmake --version
cmake version 3.20.1
$ gcc --version
gcc.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 11.2.0
$ grep 'Boost VERSION' ../../include/boost/CMakeLists.txt
project(Boost VERSION 1.78.0 LANGUAGES CXX)
$ bash --version
GNU bash, version 5.1.8(1)-release (x86_64-pc-msys)
$ systeminfo | grep 'OS '
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19042 N/A Build 19042
Just for the record (as reference), there is old PR #36 that may target similar issue.