[PATCH] Fix build issues with mingw toolchain

[Eli Zaretskii]

> Date: Fri, 10 May 2024 21:36:42 +0200
> Cc: tom@tromey.com, gdb-patches@sourceware.org
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> 
> >> frankly I don't understand at all why the _WIN32_WINNT is set to this
> >> specific value, and maybe that was a good idea when windows XP was the
> >> latest version.  My feeling would be to remove that define all together.
> >>
> >> The code looks like its intention is to raise the _WIN32_WINNT from
> >> 4.x to 5.01, but instead it lowers the _WIN32_WINNT version
> >> from 10.0 to 5.01 at least with my toolchain, where this define is not
> >> a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>,
> >> but only if it is not fixed to something else.
> > 
> > That was not the intent, and if that setting lowers the value of
> > _WIN32_WINNT, we should IMO investigate why and fix that.
> 
> Hmm, what happens here is that _WIN32_WINNT is not a pre-defined symbol,
> but __MINGW32__ is pre-defined.  So _WIN32_WINNT is not defined unless
> <windows.h> is included first, but when "gdbsupport/common-defs.h"
> is included, the _WIN32_WINNT is not yet defined, and therefore it is
> set to 0x0501, now, later when <windows.h> is included, it includes
> <_mingw.h>, but since the _WIN32_WINNT is already defined to 0x0501
> that is kept this way.  And now, the <mutex> header file wont compile,
> because the gthread.h is missing support for something similar to a
> pthread condition variable.

Thanks, I think I understand what happens, see below.

> I tried to include <windows.h> before overriding the _WIN32_WINNT define,
> but that caused issues with something like <winsock2.h> if I remember
> correctly.  I did not try to include <_mingw.h> because I expected
> that to cause even more unexpected issues, e.g. with cygwin.

No, _mingw.h is not supposed to define the default value of
_WIN32_WINNT.  It used to be w32api.h, and in mingw.org's MinGW that
still happens.  But MinGW64 deviated from that, so we need to adapt.

According to the Microsoft documentation, the default value of
_WIN32_WINNT is defined in sdkddkver.h, see

  https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170

So what we need is to have

  #include <sdkddkver.h>

before the first test of _WIN32_WINNT, and then it should work in both
flavors on MinGW.  I verified that this header defines _WIN32_WINNT in
both flavors of MinGW.

Alternatively, we could unconditionally define _WIN32_WINNT to 0x0600,
if that is needed for threading support.  AFAIU, it should not
interfere with what common-defs.h is trying to do now, since the
problem that fragment tries to solve is to make sure _WIN32_WINNT is
not defined to anything _lower_ than 0x0501.  I think this alternative
is cleaner, since sdkddkver.h is included from windows.h and defines
additional version-related constants based on _WIN32_WINNT (which
other Windows headers perhaps need).  If you decide to use this latter
alternative, please add there a comment saying that we still support
XP, but 0x0600 is required for threading when it is supported on
Windows.

> BTW: I tried the resulting executable with a Windows 10 VM, and it worked,
> but:
> 
> $ x86_64-pc-mingw32-objdump -x gdb.exe | grep DLL
>  vma:            Hint    Time      Forward  DLL       First
> 	DLL Name: bcrypt.dll
> 	DLL Name: KERNEL32.dll
> 	DLL Name: api-ms-win-crt-conio-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-convert-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-environment-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-filesystem-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-heap-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-locale-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-math-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-private-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-string-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-time-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-utility-l1-1-0.dll
> 	DLL Name: USER32.dll
> 	DLL Name: WS2_32.dll
> 
> So I am not an expert in this area, and I have not tried to run this on a
> native XP machine, but somehow I wonder if defining _WIN32_WINNT to 0x501
> does still do the trick that makes it execute on Windows XP ?

It does, I actually run GDB on Windows XP.  GDB will run on XP as long
as you don't link it against the new UCRT runtime, but against the
original MSVCRT runtime.  The above dependency DLLs seem to indicate
that your link is against UCRT, I think.  MinGW64 currently supports
both MSVCRT and UCRT builds, and mingw.org's MinGW supports only
MSVCRT.