_WIN32_WINNT redefined?

Eli Zaretskii eliz@gnu.org
Wed Nov 2 13:26:49 GMT 2022

> From: Jeffrey Walton <noloader@gmail.com>
> Date: Wed, 2 Nov 2022 09:10:21 -0400
> Cc: i.nixman@autistici.org, gdb@sourceware.org
> > > right, with commented out the entire PP block the build was successful!
> >
> > This is the wrong solution, IMO.
> Here's what Microsoft has to say about it:
> https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt
> "
>     To modify the macros, in a header file (for example, in targetver.h,
>     which is included by some project templates that target Windows),
>     add the following lines.
>     #define WINVER 0x0A00
>     #define _WIN32_WINNT 0x0A00
> If I am reading that correctly, there should be a common header file
> which defines WINVER and _WIN32_WINNT. In my old MFC days, we would
> set it in a file like <stdafx.h> . In a non-MFC project, we would set
> it under the Visual Studio preprocessor macros, which is just

I believe we use common-defs.h as that common header.

> Maybe there needs to be a configure option to set the values.

What for?  I see no reason to expose this complexity to people who
configure GDB.

The underlying problem here is that one of the two flavors of MinGW
has its headers (and _WIN32_WINNT in particular) set for Widows 9X,
and GDB no longer supports those old versions.  So we force the w32api
headers of that MinGW flavor to expose the parts that are supported on
Windows XP and later.  If the w32api headers are set for a higher
value of _WIN32_WINNT (as the other MinGW flavor already does), then
the offending part of common-defs.h should be a no-op.

Why this didn't work for the OP is unclear.  Until it is clear, IMO we
are not ready to have a rational discussion of the solutions for the

More information about the Gdb mailing list