_WIN32_WINNT redefined?

i.nixman@autistici.org i.nixman@autistici.org
Wed Nov 2 14:13:13 GMT 2022

On 2022-11-02 12:50, Eli Zaretskii wrote:

Hello Eli!

I will try to explain step by step.

the root of the issue: GDB wan't build using MinGW-W64 toolchain uses 
this patch: 
(for short, the patch provides the ability to libstdc++ to enable the 
support for std-threads and so on but without the need to use 

next, as I wrote earlier, I have faced with a trouble I can't build GDB 
using that path:
In file included from 
                  from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24:
error: '__gthread_cond_t' does not name a type; did you mean 
   163 |     __gthread_cond_t* native_handle() noexcept { return 
&_M_cond; }
       |     ^~~~~~~~~~~~~~~~

because the patch requires the _WIN32_WINNT will be set to 0x0600 or 

next, GDB's building process trying to build `gdbsupport/thread-pool.cc` 
which includes `common-defs.h` first.
then, `gdbsupport/thread-pool.cc` includes `gdbsupport/thread-pool.h` 
which includes other standard headers like 
condition_variable/mutex/thread, etc.
at this point the inclusion chain looks like this: `mutex`[1] -> 
`bits/std_mutex.h`[2] -> `bits/gthr.h`[3] -> `gthr-default.h`[4]

(note for this link: in reality that file located inside gcc sources as 
`libgcc/gthr.h`, but on target toolchain it is `bits/gthr.h` without any 
[4] https://pastebin.com/LbE0qbwu
(note for this link: I paste that file on pastebin because I want to 
show you how looks that file after applying the patch)

now look at the 4 link at line 65: `#if _WIN32_WINNT >= 0x0600`
that is, in this case the definition from within the GDB sources 
"infects" the GCC sources. do you agree that this should not be the 

well, back to the root.
please look at `gdbsupport/common-defs.h`: 

you may not believe me, but none of the inclusions above that 
preprocessor block I'm talking about include neither `windows.h` nor 
`winver.h` nothing that could tell to that preprocessor block the value 
of `_WIN32_WINNT` :)

thus, it turns out that that preprocessor block of code does not check 
and does not correct the value of `_WIN32_WINNT` but simply always 
imposes its value.

as solution I see two ways:
1) to remove that PP block completely, because as I wrote earlier - no 
one in the GDB sources refers to it.
2) to hide that PP block so that it cannot "infect" other code by by 
getting into public headers.


More information about the Gdb mailing list