Fix issue with BOOL on Windows

[johnathan-becker]

BOOL on GNUstep platforms is defined as unsigned char except on vxworks. Having this _WIN32 flag means that GNUstep GUI gorm files will not work as they are expecting unsigned char for bool.

[hmelder]

This change seems to conflict with the definition in windef.h.

Clang MSVC

In file included from D:/a/libobjc2/libobjc2/eh_win32_msvc.cc:10:
In file included from C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\um\windows.h:175:
In file included from C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\shared\windef.h:24:
C:\Program Files (x86)\Windows Kits\10\\include\10.0.22621.0\\shared\minwindef.h:157:29: error: typedef redefinition with different types ('int' vs 'unsigned char')
  157 | typedef int                 BOOL;
      |                             ^
D:/a/libobjc2/libobjc2\objc/runtime.h:137:23: note: previous definition is here
  137 | typedef unsigned char BOOL;
      |                       ^

Clang MSYS2

D:/a/libobjc2/libobjc2/objc/runtime.h:137:23: error: typedef redefinition with different types ('unsigned char' vs 'int')

  137 | typedef unsigned char BOOL;

      |                       ^

D:/a/_temp/msys64/clang64/include/minwindef.h:131:15: note: previous definition is here

  131 |   typedef int BOOL;

      |               ^

1 error generated.

[qmfrederik]

@johnathan-becker You need to set define __OBJC_BOOL (or an equivalent) to avoid MSYS2 from defining BOOL which would have a conflicting type. Also could make this an opt-in behavior by promoting STRICT_APPLE_COMPATIBILITY to a CMake option. See #309

[johnathan-becker]

@johnathan-becker You need to set define __OBJC_BOOL (or an equivalent) to avoid MSYS2 from defining BOOL which would have a conflicting type. Also could make this an opt-in behavior by promoting STRICT_APPLE_COMPATIBILITY to a CMake option. See #309

Yes i see that. I think we can just close this MR as unworkable. I will have to test rebuilding the libobjc2 library with STRICT_APPLE_COMPATIBILITY and see if that fixes the issue. It seems like this would still cause conflicts with native Windows libraries.