[PATCH] Fix build issues with mingw toolchain

[Eli Zaretskii]

> Date: Mon, 6 May 2024 19:09:37 +0200
> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> 
> On 5/6/24 16:57, Tom Tromey wrote:
> >>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> > 
> > Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue
> > Bernd> whether or not the --disable-threading option is used.
> > Bernd> The problem happens because _WIN32_WINNT is defined to 0x501
> > Bernd> before #include <mutex> which makes the compilation abort
> > Bernd> due to missing support for __gthread_cond_t in std_mutex.h,
> > Bernd> which is conditional on _WIN32_WINNT >= 0x600.
> > 
> > Bernd> Fix the case when --disable-threading is used, by only
> > Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD
> > Bernd> is defined.
> > 
> > Bernd> Additionally make the configure script try to #include <mutex>
> > Bernd> to automatically select --disable-threading when the header file
> > Bernd> is not able to compile.
> > 
> > This looks reasonable to me.  Thank you.
> > Approved-By: Tom Tromey <tom@tromey.com>
> > 
> 
> Okay, pushed.
> 
> > I wonder if we could change _WIN32_WINNT when threading is enabled, so
> > the new gcc support could be used.
> > 
> 
> 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.

> However I am not an expert in this area, and I have only tried this with
> my self-built cross-toolchain.  What I can tell, is that although I have
> no working <pthread.h> in my sysroot, the std::thread implementation seems
> to work, as long as _WIN32_WINNT is set to something >= 0x0600.

If your MinGW headers have _WIN32_WINNT set to a value higher than
0x0501, that setting should have left it alone.  Please try to figure
out why that doesn't happen in your case, perhaps MinGW64 have changed
their defaults or something.