_WIN32_WINNT redefined?

_WIN32_WINNT redefined?

[i.nixman]

hello!

host: x86_64-w64-mingw32
target: x86_64-w64-mingw32

I'm trying to build GDB using GCC that I built myself.
the GCC was patched and configured the way when std-threads implemented 
by libgcc using WINAPI directly, without winpthreads.
the compiler works, as far as I can test it.

but I have faced with a trouble with building GDB using the compiler.
the trouble looks like this:
```
In file included from 
mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/mutex:45,
                  from 
../src/gdb-11.2/gdbsupport/../gdbsupport/thread-pool.h:27,
                  from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24:
mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/bits/std_mutex.h:163:5: 
error: '__gthread_cond_t' does not name a type; did you mean 
'__gthread_once_t'?
   163 |     __gthread_cond_t* native_handle() noexcept { return 
&_M_cond; }
       |     ^~~~~~~~~~~~~~~~
```

the problem is a consequence of the fact that `_WIN32_WINNT` is 
redefined somewhere to another value that is less than necessary.
but when I pass `-D_WIN32_WINNT=0x0601` for CFLAGS/CXXFLAGS - the 
trouble is gone.

the mingw-w64-api was configured with 
`--with-default-win32-winnt=0x0601` and I can confirm the `_WIN32_WINNT` 
is actually set to the correct value.
moreover, using the compiler I can successfully build a simple program 
that uses `std::thread` without the need to pass `-D_WIN32_WINNT=0x0601` 
for CFLAGS/CXXFLAGS.


so my question is: could it be so the `_WIN32_WINNT` macro is reassigned 
somewhere in GDB sources?




best!

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 08:14, niXman via Gdb wrote:


looks like it can be defined here:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD#l81


as 0x0500 if it wasn't defined before...

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 08:21, niXman via Gdb wrote:
> On 2022-11-02 08:14, niXman via Gdb wrote:
> 
> 
> looks like it can be defined here:
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD#l81
> 
> 
> as 0x0500 if it wasn't defined before...


right, because inclusion of windows.h here 
(https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD#l74) 
after line 74 solves the trouble.


but it introduced another trouble:
```
mkdir -p -- nat/.deps
   CXX    gdb.o
   CXX    ada-exp.o
ada-exp.c.tmp:557: warning: "IN" redefined
In file included from 
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/windef.h:9,
                  from 
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/windows.h:69,
                  from 
../../../../src/gdb-11.2/gdb/../gdbsupport/common-defs.h:75,
                  from ../../../../src/gdb-11.2/gdb/defs.h:28,
                  from ada-exp.y:38:
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/minwindef.h:57: 
note: this is the location of the previous definition
    57 | #define IN
       |
ada-exp.c.tmp:482:11: error: 'INT' redeclared as different kind of 
entity
In file included from 
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/minwindef.h:163:
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/winnt.h:299:15: 
note: previous declaration 'typedef int INT'
   299 |   typedef int INT;
       |               ^~~
ada-exp.c.tmp:485:13: error: 'FLOAT' redeclared as different kind of 
entity
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/minwindef.h:142:17: 
note: previous declaration 'typedef float FLOAT'
   142 |   typedef float FLOAT;
       |                 ^~~~~
```

=)

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 08:44, niXman via Gdb wrote:
> On 2022-11-02 08:21, niXman via Gdb wrote:

ok, I did a little research.

the `_WIN32_WINNT` is defined in `gdbsupport/common-defs.h` only, but 
referenced in `gnulib/import/gettimeofdeay.c` and 
`gnulib/import/stat-w32.c` only, but not directly because those files 
include `windows,h` and `sdkdkver.h`. thus that `_WIN32_WINNT` define is 
never used!

so I think the best way is to remove that define completely.


ideas?

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 09:46, niXman via Gdb wrote:
> On 2022-11-02 08:44, niXman via Gdb wrote:
>> On 2022-11-02 08:21, niXman via Gdb wrote:
> 
> ok, I did a little research.
> 
> the `_WIN32_WINNT` is defined in `gdbsupport/common-defs.h` only, but
> referenced in `gnulib/import/gettimeofdeay.c` and
> `gnulib/import/stat-w32.c` only, but not directly because those files
> include `windows,h` and `sdkdkver.h`. thus that `_WIN32_WINNT` define
> is never used!
> 
> so I think the best way is to remove that define completely.
> 
> 
> ideas?


right, with commented out the entire PP block the build was successful!



best!

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> Date: Wed, 02 Nov 2022 09:46:20 +0000
> From: niXman via Gdb <gdb@sourceware.org>
> 
> On 2022-11-02 08:44, niXman via Gdb wrote:
> > On 2022-11-02 08:21, niXman via Gdb wrote:
> 
> ok, I did a little research.
> 
> the `_WIN32_WINNT` is defined in `gdbsupport/common-defs.h` only, but 
> referenced in `gnulib/import/gettimeofdeay.c` and 
> `gnulib/import/stat-w32.c` only, but not directly because those files 
> include `windows,h` and `sdkdkver.h`. thus that `_WIN32_WINNT` define is 
> never used!

No, _WIN32_WINNT is referenced in a lot of w32api header files, which
use it to decide whether to expose function prototypes, data type
declarations, macros, etc.  In effect, the value of _WIN32_WINNT
determines the oldest version of MS-Windows which the program needs to
support, by hiding APIs that are not available on later versions --
this ensures the program doesn't use those later APIs unintentionally.

> so I think the best way is to remove that define completely.

No, that's wrong, because if you remove that, you will basically force
everyone who builds GDB for Windows to use the default value of
_WIN32_WINNT defined by the w32api headers.  And that default is not
necessarily what we want.

> ideas?

Find out why the current definition causes trouble in your build, then
we could discuss the correct solution that works for everyone.

In the original report you said:

> In file included from 
> mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/mutex:45,
>                   from 
> ../src/gdb-11.2/gdbsupport/../gdbsupport/thread-pool.h:27,
>                   from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24:
> mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/bits/std_mutex.h:163:5: 
> error: '__gthread_cond_t' does not name a type; did you mean 
> '__gthread_once_t'?
>    163 |     __gthread_cond_t* native_handle() noexcept { return 
> &_M_cond; }
>        |     ^~~~~~~~~~~~~~~~
> ```
> 
> the problem is a consequence of the fact that `_WIN32_WINNT` is 
> redefined somewhere to another value that is less than necessary.
> but when I pass `-D_WIN32_WINNT=0x0601` for CFLAGS/CXXFLAGS - the 
> trouble is gone.

This doesn't explain why -D_WIN32_WINNT=0x0601 solves the problem.
Can you explain that in enough detail, and point to the relevant parts
of the headers?

In addition, you point to this place in common-defs.h:

  /* We don't support Windows versions before XP, so we define
     _WIN32_WINNT correspondingly to ensure the Windows API headers
     expose the required symbols.  */
  #if defined (__MINGW32__) || defined (__CYGWIN__)
  # ifdef _WIN32_WINNT
  #  if _WIN32_WINNT < 0x0501
  #   undef _WIN32_WINNT
  #   define _WIN32_WINNT 0x0501
  #  endif
  # else
  #  define _WIN32_WINNT 0x0501
  # endif
  #endif	/* __MINGW32__ || __CYGWIN__ */

This defines _WIN32_WINNT only if it wasn't already defined, or if it
was defined to a value smaller than 0x0501.  So why isn't _WIN32_WINNT
defined in your w32api headers?  It should be defined to some default
value, which was determined when the w32api headers were produced, and
I'm guessing that this default value should be 0x0601, in which case
the above preprocessor stuff should not redefine it.

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> Date: Wed, 02 Nov 2022 08:44:09 +0000
> From: niXman via Gdb <gdb@sourceware.org>
> 
> > looks like it can be defined here:
> > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD#l81
> > 
> > 
> > as 0x0500 if it wasn't defined before...
> 
> 
> right, because inclusion of windows.h here 
> (https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD#l74) 
> after line 74 solves the trouble.

Do you mean that the w32api headers you use _override_ any external
definition of _WIN32_WINNT?  They shouldn't: this macro exists to
control what w32api headers expose and what they don't, so including
windows.h should not change its value.

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> Date: Wed, 02 Nov 2022 10:15:01 +0000
> X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
>  DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS,
>  TXREP autolearn=ham autolearn_force=no version=3.4.6
> From: niXman via Gdb <gdb@sourceware.org>
> 
> On 2022-11-02 09:46, niXman via Gdb wrote:
> > On 2022-11-02 08:44, niXman via Gdb wrote:
> >> On 2022-11-02 08:21, niXman via Gdb wrote:
> > 
> > ok, I did a little research.
> > 
> > the `_WIN32_WINNT` is defined in `gdbsupport/common-defs.h` only, but
> > referenced in `gnulib/import/gettimeofdeay.c` and
> > `gnulib/import/stat-w32.c` only, but not directly because those files
> > include `windows,h` and `sdkdkver.h`. thus that `_WIN32_WINNT` define
> > is never used!
> > 
> > so I think the best way is to remove that define completely.
> > 
> > 
> > ideas?
> 
> 
> right, with commented out the entire PP block the build was successful!

This is the wrong solution, IMO.

Re: _WIN32_WINNT redefined?

[Jeffrey Walton]

On Wed, Nov 2, 2022 at 9:02 AM Eli Zaretskii via Gdb <gdb@sourceware.org> wrote:
>
> > Date: Wed, 02 Nov 2022 10:15:01 +0000
> > X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
> >  DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS,
> >  TXREP autolearn=ham autolearn_force=no version=3.4.6
> > From: niXman via Gdb <gdb@sourceware.org>
> >
> > On 2022-11-02 09:46, niXman via Gdb wrote:
> > > On 2022-11-02 08:44, niXman via Gdb wrote:
> > >> On 2022-11-02 08:21, niXman via Gdb wrote:
> > >
> > > ok, I did a little research.
> > >
> > > the `_WIN32_WINNT` is defined in `gdbsupport/common-defs.h` only, but
> > > referenced in `gnulib/import/gettimeofdeay.c` and
> > > `gnulib/import/stat-w32.c` only, but not directly because those files
> > > include `windows,h` and `sdkdkver.h`. thus that `_WIN32_WINNT` define
> > > is never used!
> > >
> > > so I think the best way is to remove that define completely.
> > >
> > >
> > > ideas?
> >
> > 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
CPPFLAGS.

Maybe there needs to be a configure option to set the values.
Configure would then create the header file with the values. If the
configure option is not supplied, then use a sane default value and
create the header file.

Jeff

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> 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
> CPPFLAGS.

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
issue.

Re: _WIN32_WINNT redefined?

[i.nixman]

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: 
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054895.html
(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 
libwinpthreads: 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/)

next, as I wrote earlier, I have faced with a trouble I can't build GDB 
using that path:
```
In file included from 
mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/mutex:45,
                  from 
../src/gdb-11.2/gdbsupport/../gdbsupport/thread-pool.h:27,
                  from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24:
mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/bits/std_mutex.h:163:5: 
error: '__gthread_cond_t' does not name a type; did you mean 
'__gthread_once_t'?
   163 |     __gthread_cond_t* native_handle() noexcept { return 
&_M_cond; }
       |     ^~~~~~~~~~~~~~~~
```

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

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]

[1] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/mutex;h=b310c15687d323c1750f717e630fbe0666515139;hb=HEAD
[2] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/std_mutex.h;h=b22e0e12793700291c65c1695313dbeae4561da2;hb=HEAD
[3] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/gthr.h;h=7943c94f6d16b7aed4269aa08db746ae131430b1;hb=HEAD
(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 
changes)
[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 
case?

well, back to the root.
please look at `gdbsupport/common-defs.h`: 
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD

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.





best!

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> Date: Wed, 02 Nov 2022 14:13:13 +0000
> From: i.nixman@autistici.org
> 
> the root of the issue: GDB wan't build using MinGW-W64 toolchain uses 
> this patch: 
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054895.html
> (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 
> libwinpthreads: 
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/)
> 
> next, as I wrote earlier, I have faced with a trouble I can't build GDB 
> using that path:
> ```
> In file included from 
> mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/mutex:45,
>                   from 
> ../src/gdb-11.2/gdbsupport/../gdbsupport/thread-pool.h:27,
>                   from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24:
> mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/bits/std_mutex.h:163:5: 
> error: '__gthread_cond_t' does not name a type; did you mean 
> '__gthread_once_t'?
>    163 |     __gthread_cond_t* native_handle() noexcept { return 
> &_M_cond; }
>        |     ^~~~~~~~~~~~~~~~
> ```
> 
> because the patch requires the _WIN32_WINNT will be set to 0x0600 or 
> greater.

Then the stuff in common-defs.h should be augmented to define
_WIN32_WINNT to the value 0x0600 or greater, if it isn't already high
enough, but only if the patch for gthreads is being used.  How exactly
to write the cpp conditional for that, I don't know, but hopefully you
will be able to figure that out.

Or maybe you should do that in gdbsupport/thread-pool.cc instead.
Whatever is easier.

One thing is certain: GDB builds on Windows that don't use the gthread
patch should not be broken by increasing the minimum value of
_WIN32_WINNT with which GDB can be built on Windows.

> 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.

I think the right solution is:

3) amend the cpp block to define _WIN32_WINNT to 0x0600 if the threads
patch is being used.

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 15:18, Eli Zaretskii wrote:

> Then the stuff in common-defs.h should be augmented to define
> _WIN32_WINNT to the value 0x0600 or greater, if it isn't already high
> enough, but only if the patch for gthreads is being used.  How exactly
> to write the cpp conditional for that, I don't know, but hopefully you
> will be able to figure that out.

no.
just for eyes:
74 #if defined (__MINGW32__) || defined (__CYGWIN__)
75 # ifdef _WIN32_WINNT
76 #  if _WIN32_WINNT < 0x0501
77 #   undef _WIN32_WINNT
78 #   define _WIN32_WINNT 0x0501
79 #  endif
80 # else
81 #  define _WIN32_WINNT 0x0501
82 # endif
83 #endif  /* __MINGW32__ || __CYGWIN__ */

the condition on line 75 is always false, because none of the inclusions 
above include neither `windows.h` nor `winver.h`.
it can be solved by inclusion `windows.h` after line 74.
but I did it and faced with another error:
```
   CXX    gdb.o
   CXX    ada-exp.o
ada-exp.c.tmp:557: warning: "IN" redefined
In file included from 
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/windef.h:9,
                  from 
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/windows.h:69,
                  from 
../../../../src/gdb-11.2/gdb/../gdbsupport/common-defs.h:75,
                  from ../../../../src/gdb-11.2/gdb/defs.h:28,
                  from ada-exp.y:38:
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/minwindef.h:57: 
note: this is the location of the previous definition
    57 | #define IN
       |
ada-exp.c.tmp:482:11: error: 'INT' redeclared as different kind of 
entity
In file included from 
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/minwindef.h:163:
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/winnt.h:299:15: 
note: previous declaration 'typedef int INT'
   299 |   typedef int INT;
       |               ^~~
ada-exp.c.tmp:485:13: error: 'FLOAT' redeclared as different kind of 
entity
C:/msys64/home/Sysuser/mingw-gcc-trunk/x86_64-trunk-win32-seh-rt_v10-rev0/mingw64/x86_64-w64-mingw32/include/minwindef.h:142:17: 
note: previous declaration 'typedef float FLOAT'
   142 |   typedef float FLOAT;
       |                 ^~~~~
```

in that case I couldn't figure out why the `ada-exp.c.tmp` file is 
mentioned in the error message but I don't see anything that looks like 
an error in the `ada-exp.c` file.
I think `ada-exp.c.tmp` is some kind of generated file... I don't know 
what and how should I fix in that case %)


> Or maybe you should do that in gdbsupport/thread-pool.cc instead.
> Whatever is easier.

I will think on it...



> One thing is certain: GDB builds on Windows that don't use the gthread
> patch should not be broken by increasing the minimum value of
> _WIN32_WINNT with which GDB can be built on Windows.

I understand.



I have another option. will try and report back.





best!

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 15:51, niXman via Gdb wrote:

> I have another option. will try and report back.

by the way.
for now I solved the issue by adding `-D_WIN32_WINNT=0x0601` to the 
CFLAGS/CXXFLAGS.
this once again confirms my opinion that the comparison in line 75 is 
always false.




best!

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> Date: Wed, 02 Nov 2022 15:51:05 +0000
> From: i.nixman@autistici.org
> 
> On 2022-11-02 15:18, Eli Zaretskii wrote:
> 
> > Then the stuff in common-defs.h should be augmented to define
> > _WIN32_WINNT to the value 0x0600 or greater, if it isn't already high
> > enough, but only if the patch for gthreads is being used.  How exactly
> > to write the cpp conditional for that, I don't know, but hopefully you
> > will be able to figure that out.
> 
> no.
> just for eyes:
> 74 #if defined (__MINGW32__) || defined (__CYGWIN__)
> 75 # ifdef _WIN32_WINNT
> 76 #  if _WIN32_WINNT < 0x0501
> 77 #   undef _WIN32_WINNT
> 78 #   define _WIN32_WINNT 0x0501
> 79 #  endif
> 80 # else
> 81 #  define _WIN32_WINNT 0x0501
> 82 # endif
> 83 #endif  /* __MINGW32__ || __CYGWIN__ */
> 
> the condition on line 75 is always false, because none of the inclusions 
> above include neither `windows.h` nor `winver.h`.

That's on your system, with your MinGW w32api headers.  But that's not
the only game in town.

> it can be solved by inclusion `windows.h` after line 74.
> but I did it and faced with another error:

That's not what I suggested.  I suggested that you augment the above
cpp conditionals such that when the gthread patch is in use,
_WIN32_WINNT is defined to 0x0600, and otherwise to 0x0501, as before.

The question is: what could be a preprocessor conditional to determine
whether the gthread patch is used, so that it could be used to augment
the above.  This is something I cannot answer, but I hope you can.

Re: _WIN32_WINNT redefined?

[i.nixman]

On 2022-11-02 16:51, Eli Zaretskii wrote:

> That's on your system, with your MinGW w32api headers.  But that's not
> the only game in town.

I'm sure there is no WINAPI implementation that does not define 
_WIN32_WINNT. it's just impossible.
but in line 75 the condition is exactly for that impossible case.



> That's not what I suggested.  I suggested that you augment the above
> cpp conditionals such that when the gthread patch is in use,
> _WIN32_WINNT is defined to 0x0600, and otherwise to 0x0501, as before.
> 
> The question is: what could be a preprocessor conditional to determine
> whether the gthread patch is used, so that it could be used to augment
> the above.  This is something I cannot answer, but I hope you can.

I solved my problem.
What I'm doing now is trying to tell you that it's illogical to check 
the value of _WIN32_WINNT BEFORE the corresponding header file in which 
this value was originally defined, has been included.





best!

Re: _WIN32_WINNT redefined?

[Eli Zaretskii]

> Date: Wed, 02 Nov 2022 17:20:50 +0000
> From: i.nixman@autistici.org
> 
> On 2022-11-02 16:51, Eli Zaretskii wrote:
> 
> > That's on your system, with your MinGW w32api headers.  But that's not
> > the only game in town.
> 
> I'm sure there is no WINAPI implementation that does not define 
> _WIN32_WINNT. it's just impossible.
> but in line 75 the condition is exactly for that impossible case.

It is not impossible.

I use mingw.org's MinGW, where the header which defines _WIN32_WINNT
is included by every header file.  So as soon as you #include
anything, _WIN32_WINNT is already defined.

Maybe it isn't so in the headers you are using, but that doesn't mean
it is so for everyone.

And I don't see how is that relevant: even if _WIN32_WINNT is
undefined before that place, my suggestion is to change this:

 # else
 #  define _WIN32_WINNT 0x0501

into something that defines _WIN32_WINNT to 0x0600 under the condition
that the gthread patch is being used, and to 0x0501 otherwise.  This
should solve everyone's problem, right?

> What I'm doing now is trying to tell you that it's illogical to check 
> the value of _WIN32_WINNT BEFORE the corresponding header file in which 
> this value was originally defined, has been included.

See above: that is not necessarily what happens, not in all the cases
anyway.