[Bug libstdc++/108225] New: cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[Bug libstdc++/108225] New: cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

            Bug ID: 108225
           Summary: cross build gdb error for libstdc++'s std_mutex.h on
                    x86_64-w64-mingw32 host
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:151:7:
error: '__gthread_cond_init_function' was not declared in this scope; did you
mean '__gthread_mutex_init_functio
'?
  151 |       __GTHREAD_COND_INIT_FUNCTION(&_M_cond);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h
 In destructor 'std::__condvar::~__condvar()':
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:157:69:
error: '_M_cond' was not declared in this scope
  157 |       int __e __attribute__((__unused__)) =
__gthread_cond_destroy(&_M_cond);
      |                                                                    
^~~~~~~
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:157:45:
error: '__gthread_cond_destroy' was not declared in this scope; did you mean
'__gthread_mutex_destroy'?
  157 |       int __e __attribute__((__unused__)) =
__gthread_cond_destroy(&_M_cond);
      |                                             ^~~~~~~~~~~~~~~~~~~~~~
      |                                             __gthread_mutex_destroy

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
a.cc include mutex

#include<mutex>


x86_64-w64-mingw32-g++ -o a a.cc -Ofast -std=c++23 -s -flto -march=native
-D_WIN32_WINNT=0x0500

(Any value which is below 0x0500 since GDB defines it with a lower value)

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
Created attachment 54171
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54171&action=edit
Error message

This is an example of how incorrectly discarding the support of old systems
would randomly cause build issues.

Please stop! Windows 95 support is extremely important

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #2)
> Created attachment 54171 [details]
> Error message
> 
> This is an example of how incorrectly discarding the support of old systems
> would randomly cause build issues.
> 
> Please stop! Windows 95 support is extremely important


libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build failure
for gdb

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #3)
> (In reply to cqwrteur from comment #2)
> > Created attachment 54171 [details]
> > Error message
> > 
> > This is an example of how incorrectly discarding the support of old systems
> > would randomly cause build issues.
> > 
> > Please stop! Windows 95 support is extremely important
> 
> 
> libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build
> failure for gdb

The entire win32 thread model is a mess. It does not support the thread model
well enough while causing enormous pain. If users need threading, they can use
posix and mcf. Why win32??

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #4)
> (In reply to cqwrteur from comment #3)
> > (In reply to cqwrteur from comment #2)
> > > Created attachment 54171 [details]
> > > Error message
> > > 
> > > This is an example of how incorrectly discarding the support of old systems
> > > would randomly cause build issues.
> > > 
> > > Please stop! Windows 95 support is extremely important
> > 
> > 
> > libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build
> > failure for gdb
> 
> The entire win32 thread model is a mess. It does not support the thread
> model well enough while causing enormous pain. If users need threading, they
> can use posix and mcf. Why win32??

BTW who gives you the luxury to include<windows.h> in public header? windows.h
causes enormous pain.

if you need them, you should use __asm__ macro to deal with apis in windows.h
instead of including them.

#if defined(_MSC_VER) && !defined(__clang__)
__declspec(dllimport)
#elif (__has_cpp_attribute(__gnu__::__dllimport__)&&!defined(__WINE__))
[[__gnu__::__dllimport__]]
#endif
#if (__has_cpp_attribute(__gnu__::__stdcall__)&&!defined(__WINE__))
[[__gnu__::__stdcall__]]
#endif
extern void*
#if (!__has_cpp_attribute(__gnu__::__stdcall__)&&!defined(__WINE__)) &&
defined(_MSC_VER)
__stdcall
#endif
MapViewOfFile(void*,std::uint_least32_t,std::uint_least32_t,std::uint_least32_t,std::size_t)
noexcept
#if defined(__clang__) || defined(__GNUC__)
#if SIZE_MAX<=UINT_LEAST32_MAX &&(defined(__x86__) || defined(_M_IX86) ||
defined(__i386__))
#if !defined(__clang__)
__asm__("MapViewOfFile@20")
#else
__asm__("_MapViewOfFile@20")
#endif
#else
__asm__("MapViewOfFile")
#endif
#endif
;

This is how you use them.

windows.h causes massive compilation speed to slow down.

[Bug libstdc++/108225] cross build gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #6 from cqwrteur <unlvsur at live dot com> ---
x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc/./isl/include
-I/home/cqwrteur/toolchains_build/gcc/isl/include  -o cp/cvt.o -MT cp/cvt.o
-MMD -MP -MF cp/.deps/cvt.TPo /home/cqwrteur/toolchains_build/gcc/gcc/cp/cvt.cc
make[2]: *** [Makefile:1148: diagnostic-color.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected
identifier before string constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or
'...' before string constant
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected
identifier before string constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or
'...' before string constant

It looks like macro pollution also causes the Canadian compilation for GCC to
fail. __FILE__ macro fails.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-01-04

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
What GCC sources do you use?  What does 'gcc -v' output?  The error you get is
the usual error when trying to include <mutex> for a threading model not
supporting C++11 mutexes, which is the case for the Win32 threading model.

Btw the code goes to great length to avoid including <windows.h> from the
libstdc++ header files (see __GTHREAD_HIDE_WIN32API) so it is definitely not.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #7)
> Btw the code goes to great length to avoid including <windows.h> from the
> libstdc++ header files (see __GTHREAD_HIDE_WIN32API) so it is definitely not.

This reporter has a habit of glancing at the code, making assumptions, then
insulting us for things we didn't do.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #2)
> Please stop! Windows 95 support is extremely important

No it isn't.

(In reply to cqwrteur from comment #4)
> The entire win32 thread model is a mess. It does not support the thread
> model well enough while causing enormous pain. If users need threading, they
> can use posix and mcf. Why win32??

If you don't want to use the win32 model, you don't have to use it.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|WAITING                     |RESOLVED

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #3)
> libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build
> failure for gdb

If GDB requires <mutex> then it requires working C++11 thread support, which
has never worked for the win32 thread model with -D_WIN32_WINNT=0x0500.

With GCC 12, gthr-win32.h simply doesn't support std::mutex, period.

With GCC 13 it supports it for modern Windows versions:

/* Condition variables are supported on Vista and Server 2008 or later.  */
#if _WIN32_WINNT >= 0x0600
#define __GTHREAD_HAS_COND 1
#define __GTHREADS_CXX0X 1
#endif

For older Windows versions, the win32 thread model doesn't support std::mutex
etc.

There is no C++11 threading support for Win95 using --enable-threads=win32. If
you don't like it, either don't compile for Win95 or use a different thread
model.

Ranting and raving that unsupported things don't work is a waste of time.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|WONTFIX                     |---

--- Comment #11 from cqwrteur <unlvsur at live dot com> ---
The problem is that it breaks gcc build too. GCC won't build any more due to
macro pollution of __FILE__

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #12 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #11)
> The problem is that it breaks gcc build too. GCC won't build any more due to
> macro pollution of __FILE__

x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc/./isl/include
-I/home/cqwrteur/toolchains_build/gcc/isl/include  -o cp/cvt.o -MT cp/cvt.o
-MMD -MP -MF cp/.deps/cvt.TPo /home/cqwrteur/toolchains_build/gcc/gcc/cp/cvt.cc
make[2]: *** [Makefile:1148: diagnostic-color.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected
identifier before string constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or
'...' before string constant
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected
identifier before string constant
  791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
      |                              ^~~~~~~~
/home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or
'...' before string constant

It looks like macro pollution also causes the Canadian compilation for GCC to
fail. __FILE__ macro fails.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That's PR 108300 and has nothing to do with "macro pollution of __FILE__".

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And it isn't specific to Canadian cross compilation either. It happens for any
build with the latest mingw-w64 headers, both native and cross. And that has
nothing to do with std::mutex, which is the subject of this bug report.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |REOPENED

--- Comment #15 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #14)
> And it isn't specific to Canadian cross compilation either. It happens for
> any build with the latest mingw-w64 headers, both native and cross. And that
> has nothing to do with std::mutex, which is the subject of this bug report.

#if _WIN32_WINNT >= 0x0600
#define __GTHREAD_HAS_COND 1
#define __GTHREADS_CXX0X 1
#endif

I suggest remove this macro in the header due to potential breakage

#if _WIN32_WINNT >= 0x0600
#endif

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|REOPENED                    |RESOLVED

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> #if _WIN32_WINNT >= 0x0600
> #define __GTHREAD_HAS_COND 1
> #define __GTHREADS_CXX0X 1
> #endif
> 
> I suggest remove this macro in the header due to potential breakage
> 
> #if _WIN32_WINNT >= 0x0600
> #endif

That's nonsensical.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
         Resolution|WONTFIX                     |---

--- Comment #17 from cqwrteur <unlvsur at live dot com> ---
(In reply to Eric Botcazou from comment #16)
> > #if _WIN32_WINNT >= 0x0600
> > #define __GTHREAD_HAS_COND 1
> > #define __GTHREADS_CXX0X 1
> > #endif
> > 
> > I suggest remove this macro in the header due to potential breakage
> > 
> > #if _WIN32_WINNT >= 0x0600
> > #endif
> 
> That's nonsensical.

The problem is that libstdc++ would instantly break if someone randomly defines
_WIN32_WINNT (like gdb does).

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #18 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #17)
> (In reply to Eric Botcazou from comment #16)
> > > #if _WIN32_WINNT >= 0x0600
> > > #define __GTHREAD_HAS_COND 1
> > > #define __GTHREADS_CXX0X 1
> > > #endif
> > > 
> > > I suggest remove this macro in the header due to potential breakage
> > > 
> > > #if _WIN32_WINNT >= 0x0600
> > > #endif
> > 
> > That's nonsensical.
> 
> The problem is that libstdc++ would instantly break if someone randomly
> defines _WIN32_WINNT (like gdb does).

The solution would probably be for libstdc++ to guard against
__GHTREAD_HAS_COND instead

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #19 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #18)
> (In reply to cqwrteur from comment #17)
> > (In reply to Eric Botcazou from comment #16)
> > > > #if _WIN32_WINNT >= 0x0600
> > > > #define __GTHREAD_HAS_COND 1
> > > > #define __GTHREADS_CXX0X 1
> > > > #endif
> > > > 
> > > > I suggest remove this macro in the header due to potential breakage
> > > > 
> > > > #if _WIN32_WINNT >= 0x0600
> > > > #endif
> > > 
> > > That's nonsensical.
> > 
> > The problem is that libstdc++ would instantly break if someone randomly
> > defines _WIN32_WINNT (like gdb does).
> 
> The solution would probably be for libstdc++ to guard against
> __GHTREAD_HAS_COND instead

https://sourceware.org/bugzilla/show_bug.cgi?id=29966

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #20 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #19)
> (In reply to cqwrteur from comment #18)
> > (In reply to cqwrteur from comment #17)
> > > (In reply to Eric Botcazou from comment #16)
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #define __GTHREAD_HAS_COND 1
> > > > > #define __GTHREADS_CXX0X 1
> > > > > #endif
> > > > > 
> > > > > I suggest remove this macro in the header due to potential breakage
> > > > > 
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #endif
> > > > 
> > > > That's nonsensical.
> > > 
> > > The problem is that libstdc++ would instantly break if someone randomly
> > > defines _WIN32_WINNT (like gdb does).
> > 
> > The solution would probably be for libstdc++ to guard against
> > __GHTREAD_HAS_COND instead
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29966

D:\msys64\home\unlvs\projects\fast_io\examples\0001.helloworld>g++ -o
helloworld helloworld.cc -Ofast -std=c++23 -s -flto -march=native
-I../../include
d:/x86_64-windows-gnu/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
helloworld.exe:.rdata_r: section below image base

Do not know why.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=29966
             Status|WAITING                     |RESOLVED
         Resolution|---                         |MOVED

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #18)
> The solution would probably be for libstdc++ to guard against
> __GHTREAD_HAS_COND instead

No it wouldn't, you don't know what you're talking about.

That's defined under exactly the same condition as the __GTHREADS_CXX0X macro
that libstdc++ uses, so it would make no difference at all.

This is a GDB bug which has a configure check for std::thread which doesn't
work with GCC 13. See the linked GDB bug report.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #22 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #19)
> (In reply to cqwrteur from comment #18)
> > (In reply to cqwrteur from comment #17)
> > > (In reply to Eric Botcazou from comment #16)
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #define __GTHREAD_HAS_COND 1
> > > > > #define __GTHREADS_CXX0X 1
> > > > > #endif
> > > > > 
> > > > > I suggest remove this macro in the header due to potential breakage
> > > > > 
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #endif
> > > > 
> > > > That's nonsensical.
> > > 
> > > The problem is that libstdc++ would instantly break if someone randomly
> > > defines _WIN32_WINNT (like gdb does).
> > 
> > The solution would probably be for libstdc++ to guard against
> > __GHTREAD_HAS_COND instead
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29966

not working 

d-pool.cc:21:
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:164:5:
error: '__gthread_cond_t' does not name a type; did you mean
'__gthread_once_t'?
  164 |     __gthread_cond_t* native_handle() noexcept { return &_M_cond; }
      |     ^~~~~~~~~~~~~~~~
      |     __gthread_once_t
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:208:5:
error: '__gthread_cond_t' does not name a type; did you mean
'__gthread_once_t'?
  208 |     __gthread_cond_t _M_cond;
      |     ^~~~~~~~~~~~~~~~
      |     __gthread_once_t
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:
In constructor 'std::__condvar::__condvar()':
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:151:37:
error: '_M_cond' was not declared in this scope
  151 |       __GTHREAD_COND_INIT_FUNCTION(&_M_cond);
      |                                     ^~~~~~~
  CC       ldcref.o

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
         Resolution|MOVED                       |---

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|WAITING                     |RESOLVED

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|MOVED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The problem now is that using a different value of _WIN32_WINNT invalidates
what was used during libstdc++'s configure, making _GLIBCXX_HAS_GTHREADS
incorrect.

Maybe we want something like this:

diff --git a/libstdc++-v3/config/os/mingw32-w64/os_defines.h
b/libstdc++-v3/config/os/mingw32-w64/os_defines.h
index ee02ff82e86..68ac100acc8 100644
--- a/libstdc++-v3/config/os/mingw32-w64/os_defines.h
+++ b/libstdc++-v3/config/os/mingw32-w64/os_defines.h
@@ -96,4 +96,13 @@
 // See libstdc++/94268
 #define _GLIBCXX_BUFSIZ 4096

+#if _WIN32_WINNT < 0x0600
+// For the win32 thread model, setting _WIN32_WINNT to an old version might
+// invalidate the value of _GLIBCXX_HAS_GTHREADS decided during configure.
+# include <gthr.h>
+# ifndef __GTHREADS_CXX0X
+#  undef _GLIBCXX_HAS_GTHREADS
+# endif
+#endif
+
 #endif

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Maybe we want something like this:
> 
> diff --git a/libstdc++-v3/config/os/mingw32-w64/os_defines.h
> b/libstdc++-v3/config/os/mingw32-w64/os_defines.h
> index ee02ff82e86..68ac100acc8 100644
> --- a/libstdc++-v3/config/os/mingw32-w64/os_defines.h
> +++ b/libstdc++-v3/config/os/mingw32-w64/os_defines.h
> @@ -96,4 +96,13 @@
>  // See libstdc++/94268
>  #define _GLIBCXX_BUFSIZ 4096
>  
> +#if _WIN32_WINNT < 0x0600
> +// For the win32 thread model, setting _WIN32_WINNT to an old version might
> +// invalidate the value of _GLIBCXX_HAS_GTHREADS decided during configure.
> +# include <gthr.h>
> +# ifndef __GTHREADS_CXX0X
> +#  undef _GLIBCXX_HAS_GTHREADS
> +# endif
> +#endif
> +
>  #endif

IMO either you do not test _WIN32_WINNT but just __GTHREADS_CXX0X, or you just
test _WIN32_WINNT and avoiding including <gthr.h> & testing __GTHREADS_CXX0X.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For --enable-threads=posix the value of _WIN32_WINNT doesn't matter, so we
don't want to disable _GLIBCXX_HAS_GTHREADS in that case. That's why we need to
include <gthr.h>, to find out if it's actually affected by _WIN32_WINNT.

But IMHO we don't want to include <gthr.h> unconditionally in every single
libstdc++ header (because they all include <bits/c++config.h> which includes
this os_defines.h header). So only do it if _WIN32_WINNT has been set to some
ancient value, because otherwise the problem doesn't exist.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> For --enable-threads=posix the value of _WIN32_WINNT doesn't matter, so we
> don't want to disable _GLIBCXX_HAS_GTHREADS in that case. That's why we need
> to include <gthr.h>, to find out if it's actually affected by _WIN32_WINNT.

OK, indeed I totally overlooked the other threading models...

> But IMHO we don't want to include <gthr.h> unconditionally in every single
> libstdc++ header (because they all include <bits/c++config.h> which includes
> this os_defines.h header). So only do it if _WIN32_WINNT has been set to
> some ancient value, because otherwise the problem doesn't exist.

Fair enough, although it only drags stdlib.h and sys/timeb.h if you define
__GTHREAD_HIDE_WIN32API like libstdc++ does.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
   Target Milestone|---                         |13.0
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Gah, this doesn't work (and not only because it should be <bits/gthr.h> not
<gthr.h>).

We include os_defines.h before the line create by configure:
#include <bits/os_defines.h>
...
#define _GLIBCXX_HAS_GTHREADS 1

I have a fix, but it will have to wait for higher priority things to be done
first.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #2)
> Please stop! Windows 95 support is extremely important

Looks like you can't even include <string> if you set _WIN32_WINNT < 0x0600 so
this has NEVER worked, and I don't see why we should waste our time supporting
it.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #29 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think if you want to build for ancient versions < 0x0600 then you should
build a custom toolchain for that. Build the whole compiler with
--enable-cxx-flags="-O2 -g -D_WIN32_WINNT=0x0500" and that way libstdc++'s
configure will correctly detect at build time that you are from prehistoric
times. It will correctly disable uses of C99 stdlib.h and C++11 mutexes and
threads etc.

Building a compiler for modern Windows versions and expecting it to also
compile for ancient versions is not going to work. Treat the ancient versions
as a cross-compilation target and use a custom toolchain instead.

So I'm closing this again.

[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 54255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54255&action=edit
Disable C++11 mutex etc. when not supported by win32 threads

This patch would solve the problem for <mutex> and <thread>, but would not do
anything about the fact that this would still fail:

#define _WIN32_WINNT 0x0502
#include <string>

If you can't even include <string> then the library is unusable, so we're not
going to attempt to support that.

As I said in the last comment, it will work if libstdc++ is configured with the
ancient value of _WIN32_WINNT, but selecting those ancient versions after
installation by defining it in your own code won't work. I'll document this in
the manual.