[Bug build/29966] New: Cannot build anymore for win32 thread model of gdb

[Bug build/29966] New: Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

            Bug ID: 29966
           Summary: Cannot build anymore for win32 thread model of gdb
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: euloanty at live dot com
  Target Milestone: ---

Recently gcc added some changes to win32 thread model

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-01-06
                 CC|                            |tromey at sourceware dot org
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
We need more information to understand the problem.
At the very least the failing compilation and error messages
would be good.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |euloanty at live dot com

--- Comment #2 from cqwrteur <euloanty at live dot com> ---
Created attachment 14562
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14562&action=edit
config

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #3 from cqwrteur <euloanty at live dot com> ---
Created attachment 14563
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14563&action=edit
err

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Can you send gdbsupport/config.log?
I think that would show what the thread checks are doing.
gdb's configury is set up to try to adapt to a non-working
std::thread, so maybe that has stopped working somehow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
Also, what sort of system are you on?
Internally at AdaCore we use some variant of that gcc patch,
I believe, and it's been working fine for quite a while.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #6 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #4)
> Can you send gdbsupport/config.log?
> I think that would show what the thread checks are doing.
> gdb's configury is set up to try to adapt to a non-working
> std::thread, so maybe that has stopped working somehow.

GCC's win32 thread model updates win32 thread. It wasn't working before.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #6)
> (In reply to Tom Tromey from comment #4)
> > Can you send gdbsupport/config.log?
> > I think that would show what the thread checks are doing.
> > gdb's configury is set up to try to adapt to a non-working
> > std::thread, so maybe that has stopped working somehow.
> 
> GCC's win32 thread model updates win32 thread. It wasn't working before.

Previously it didn't work at all and gdb's configure check
correctly detected this and disabled threading.

These checks no longer seem to be working correctly, as
evidenced by the errors you see.

To adapt to this change, we need to understand why the configure
checks did not do their job.

This is why I would like to see your gdbsupport/config.log.
That should contain some clues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #8 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #7)
> (In reply to cqwrteur from comment #6)
> > (In reply to Tom Tromey from comment #4)
> > > Can you send gdbsupport/config.log?
> > > I think that would show what the thread checks are doing.
> > > gdb's configury is set up to try to adapt to a non-working
> > > std::thread, so maybe that has stopped working somehow.
> > 
> > GCC's win32 thread model updates win32 thread. It wasn't working before.
> 
> Previously it didn't work at all and gdb's configure check
> correctly detected this and disabled threading.
> 
> These checks no longer seem to be working correctly, as
> evidenced by the errors you see.
> 
> To adapt to this change, we need to understand why the configure
> checks did not do their job.
> 
> This is why I would like to see your gdbsupport/config.log.
> That should contain some clues.

The issue is that gdb will set -D_WIN32_WINNT to a lower value than it expects.
Then the win32 threading will no longer compile with libstdc++.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #8)

> > This is why I would like to see your gdbsupport/config.log.
> > That should contain some clues.
> 
> The issue is that gdb will set -D_WIN32_WINNT to a lower value than it
> expects. Then the win32 threading will no longer compile with libstdc++.

Last time I tried to bump up _WIN32_WINNT, some users pushed back.
What's the minimum supported by libstdc++?  For gdbsupport it seems to be:

#   define _WIN32_WINNT 0x0501

Anyway -- can you send the config.log?
We can then arrange to build gdb without threading in this case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #10 from cqwrteur <euloanty at live dot com> ---
Created attachment 14564
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14564&action=edit
all logs in gdbsupport

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #11 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #9)
> (In reply to cqwrteur from comment #8)
> 
> > > This is why I would like to see your gdbsupport/config.log.
> > > That should contain some clues.
> > 
> > The issue is that gdb will set -D_WIN32_WINNT to a lower value than it
> > expects. Then the win32 threading will no longer compile with libstdc++.
> 
> Last time I tried to bump up _WIN32_WINNT, some users pushed back.
> What's the minimum supported by libstdc++?  For gdbsupport it seems to be:
> 
> #   define _WIN32_WINNT 0x0501
> 
> Anyway -- can you send the config.log?
> We can then arrange to build gdb without threading in this case.

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

I think this is something also wrong with gcc and libstdc++ too. mutex should
not break if someone defines _WIN32_WINNT macro i think.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com

--- Comment #12 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
For libstdc++ I have no interest whatsoever in supporting Windows 98 and other
dinosaurs. The win32 thread model that was previously completely non-functional
now supports C++11 std::mutex etc. but only for "Windows Vista and Server 2008
or later" (to quote the comment in gthr-win32.h). If you define _WIN32_WINNT to
an older value, you can't use std::mutex etc. That's not "something also wrong
with gcc and libstdc++ too", it's just reality.

So if GDB wants to use threads for a mingw target that uses
--enable-threads=win32 (rather than --enable-thread=posix via libwinpthreads)
then it needs to target Vista or Server 2008 or later. Otherwise, if it wants
to target older versions of Windows, then it needs to not use std::mutex etc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #13 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #12)
> For libstdc++ I have no interest whatsoever in supporting Windows 98 and
> other dinosaurs. The win32 thread model that was previously completely
> non-functional now supports C++11 std::mutex etc. but only for "Windows
> Vista and Server 2008 or later" (to quote the comment in gthr-win32.h). If
> you define _WIN32_WINNT to an older value, you can't use std::mutex etc.
> That's not "something also wrong with gcc and libstdc++ too", it's just
> reality.
> 
> So if GDB wants to use threads for a mingw target that uses
> --enable-threads=win32 (rather than --enable-thread=posix via
> libwinpthreads) then it needs to target Vista or Server 2008 or later.
> Otherwise, if it wants to target older versions of Windows, then it needs to
> not use std::mutex etc.

but you can make std::conditional_variable a nop if __GTHR_COND is not defined
to prevent silent breakage right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #14 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
The problem is that common.m4 does this:

  # Check for std::thread.  This does not work on some platforms, like
  # mingw and DJGPP.
  AC_LANG_PUSH([C++])
  AX_PTHREAD([threads=yes], [threads=no])
  save_LIBS="$LIBS"
  LIBS="$PTHREAD_LIBS $LIBS"
  save_CXXFLAGS="$CXXFLAGS"
  CXXFLAGS="$PTHREAD_CFLAGS $save_CXXFLAGS"
  AC_CACHE_CHECK([for std::thread],
                 gdb_cv_cxx_std_thread,
                 [AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
  [[#include <thread>
    void callback() { }]],
  [[std::thread t(callback);]])],
                                gdb_cv_cxx_std_thread=yes,
                                gdb_cv_cxx_std_thread=no)])

  if test "$threads" = "yes"; then
    # This check must be here, while LIBS includes any necessary
    # threading library.
    AC_CHECK_FUNCS([pthread_sigmask pthread_setname_np])
  fi
  LIBS="$save_LIBS"
  CXXFLAGS="$save_CXXFLAGS"

  if test "$want_threading" = "yes"; then
    if test "$gdb_cv_cxx_std_thread" = "yes"; then
      AC_DEFINE(CXX_STD_THREAD, 1,
                [Define to 1 if std::thread works.])
    fi
  fi
  AC_LANG_POP


For the win32 thread model in GCC 13, that will compile using the default value
of _WIN32_WINNT. So configure decides that std::thread is available. But in
comon-defs.h you explicitly define _WIN32_WINNT to an older value, which means
std::thread is not available.

The configure check should use the same value of _WIN32_WINNT.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #15 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to cqwrteur from comment #13)
> but you can make std::conditional_variable a nop if __GTHR_COND is not
> defined to prevent silent breakage right?

There is no silent breakage. It's very very noisy breakage, because
std::condition_variable isn't defined, so doesn't compile.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #16 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to Jonathan Wakely from comment #14)
> For the win32 thread model in GCC 13, that will compile using the default
> value of _WIN32_WINNT. So configure decides that std::thread is available.
> But in comon-defs.h you explicitly define _WIN32_WINNT to an older value,
> which means std::thread is not available.

Before GCC 13 the configure check worked, because the win32 thread model never
provided std::thread, period. So it didn't matter that configure and
common-defs.h don't use the same value of _WIN32_WINNT, because the
availability of std::thread didn't depend on that macro. That has changed in
GCC 13 with Eric B's patch to make the win32 thread model functional, but only
for some values of _WIN32_WINNT:

/* 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

So now common.m4 needs to be consistent with common-defs.h

IMHO you should just bump _WIN32_WINNT and stop supporting ancient versions of
Windows that MS dropped support for long ago. But that's GDB's call.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #17 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
The relevant part of gdbsupport/config.log is:

configure:8963: checking for std::thread
configure:8980: x86_64-w64-mingw32-g++ -c  -g -O2      conftest.cpp >&5
configure:8980: $? = 0
configure:8987: result: yes

And that's exactly what I'd expect given the snippet shown in comment 14 above.
So it defines CXX_STD_THREAD and then thread-pool.h does:

#if CXX_STD_THREAD
#include <thread>
#include <mutex>
#include <condition_variable>
#include <future>
#endif

But thread-pool.cc includes that after common-defs.h:

#include "common-defs.h"
#include "gdbsupport/thread-pool.h"

So _WIN32_WINNT is set before including thread-pool.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__ */

So when thread-pool.h includes <mutex> it doesn't actually get a definition of
std::mutex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #18 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Jonathan Wakely from comment #16)

> So now common.m4 needs to be consistent with common-defs.h

Thanks for the diagnosis.  I'll come up with a patch sometime soon.
Not sure I can really test it, but I can at least do a mingw cross
build.

> IMHO you should just bump _WIN32_WINNT and stop supporting ancient versions
> of Windows that MS dropped support for long ago. But that's GDB's call.

Yeah, I tried that but there's a contributor on an older version:

https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html

I didn't look to see if there's some version between what we have
and what I tried that time.  I don't remember the details really,
I just remember thinking that the choice in that patch eliminated
versions of Windows that are out of support.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org
             Status|WAITING                     |NEW

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #19 from Tom Tromey <tromey at sourceware dot org> ---
Could you please try this patch?

https://sourceware.org/pipermail/gdb-patches/2023-January/195484.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #20 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #19)
> Could you please try this patch?
> 
> https://sourceware.org/pipermail/gdb-patches/2023-January/195484.html

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

So the variable needs to be larger than 0x0600

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #21 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to cqwrteur from comment #20)
> So the variable needs to be larger than 0x0600

No, it doesn't! It just needs to be consistent between configure and
common-defs.h

If you don't define it yourself when building GDB, both files define it to
0x0501, and C++11 threads are disabled. This is fine.

If you do define it, then they are either enabled or disabled according to the
value you use. This is fine.

I haven't tested the patch myself, so please do so, since you are the one with
the affected target set up already.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #22 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #20)
> (In reply to Tom Tromey from comment #19)
> > Could you please try this patch?
> > 
> > https://sourceware.org/pipermail/gdb-patches/2023-January/195484.html
> 
> #if _WIN32_WINNT >= 0x0600
> #define __GTHREAD_HAS_COND 1
> #define __GTHREADS_CXX0X 1
> #endif
> 
> So the variable needs to be larger than 0x0600

Let me agree here with Jonathan.
The goal of the patch is not to somehow make threads work on
your system.  That can't be done by gdb configure.
The goal is to correctly detect the problem and disable
threading support in gdb.

Did you try the patch?
If so, please report the (presumably new) problem.
If not, please apply it and do a clean build.
Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #23 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #20)
> (In reply to Tom Tromey from comment #19)
> > Could you please try this patch?
> > 
> > https://sourceware.org/pipermail/gdb-patches/2023-January/195484.html
> 
> #if _WIN32_WINNT >= 0x0600
> #define __GTHREAD_HAS_COND 1
> #define __GTHREADS_CXX0X 1
> #endif
> 
> So the variable needs to be larger than 0x0600

4-w64-mingw32/artifacts/targetbuild/x86_64-w64-mingw32/binutils-gdb/bfd'
  MAKEINFO doc/bfd.info
bfd.texi:246: @include: could not find init.texi
make[3]: *** [Makefile:1785: doc/bfd.info] Error 1
make[3]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/native/x86_64-w64-mingw32/artifacts/targetbuild/x86_64-w64-mingw32/binutils-gdb/bfd'
make[2]: *** [Makefile:1945: info-recursive] Error 1
make[2]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/native/x86_64-w64-mingw32/artifacts/targetbuild/x86_64-w64-mingw32/binutils-gdb/bfd'
make[1]: *** [Makefile:3090: all-bfd] Error 2
make[1]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/native/x86_64-w64-mingw32/artifacts/targetbuild/x86_64-w64-mingw32/binutils-gdb'
make: *** [Makefile:1012: all] Error 2

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #24 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
That looks completely unrelated.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #25 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Jonathan Wakely from comment #24)
> That looks completely unrelated.

Yeah:

https://sourceware.org/pipermail/binutils/2023-January/125593.html

I guess you'll have to update & rebase to try again.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #26 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #25)
> (In reply to Jonathan Wakely from comment #24)
> > That looks completely unrelated.
> 
> Yeah:
> 
> https://sourceware.org/pipermail/binutils/2023-January/125593.html
> 
> I guess you'll have to update & rebase to try again.

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

not working

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #27 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #26)

> not working

Can you send gdbsupport/config.log?
That's the important part.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #28 from cqwrteur <euloanty at live dot com> ---
Created attachment 14573
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14573&action=edit
log file

log

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #29 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
This time it looks like it's a similar problem in libstdc++. During the
configure step _WIN32_WINNT is defined such that _GLIBCXX_HAS_GTHREADS gets
defined, but then you override it later, and that invalidates
_GLIBCXX_HAS_GTHREADS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #30 from Tom Tromey <tromey at sourceware dot org> ---
Jonathan pointed out the proposed libstdc++ fix:

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[cvs-commit at gcc dot gnu.org]

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

--- Comment #31 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2124b2de4bba05063218501dcccfc4cffe648cda

commit 2124b2de4bba05063218501dcccfc4cffe648cda
Author: Tom Tromey <tromey@adacore.com>
Date:   Mon Jan 9 07:43:29 2023 -0700

    Set _WIN32_WINNT in common.m4 configure check

    GCC recently added support for the Windows thread model, enabling
    libstdc++ to support Windows natively.  However, this supporrt
    requires a version of Windows later than the minimum version that is
    supported by GDB.

    PR build/29966 points out that the GDB configure test for std::thread
    does not work in this situation, because _WIN32_WINNT is not defined
    in test program, and so <thread> seems to be fine.

    This patch is an attempt to fix the problem, by using the same setting
    for _WIN32_WINNT at configure time as is used at build time.

    I don't have access to one of the older systems so I don't think I can
    truly test this.  I did do a mingw cross build, though.  I'm going to
    ask the bug reporter to test it.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #32 from Tom Tromey <tromey at sourceware dot org> ---
I'm going to leave this open while we ponder whether to
put it on the GDB 13 branch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-13-branch branch has been updated by Tom Tromey
<tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3cc048fc6b1f29ea7f5de83815e56884bbd05f61

commit 3cc048fc6b1f29ea7f5de83815e56884bbd05f61
Author: Tom Tromey <tromey@adacore.com>
Date:   Mon Jan 9 07:43:29 2023 -0700

    Set _WIN32_WINNT in common.m4 configure check

    GCC recently added support for the Windows thread model, enabling
    libstdc++ to support Windows natively.  However, this supporrt
    requires a version of Windows later than the minimum version that is
    supported by GDB.

    PR build/29966 points out that the GDB configure test for std::thread
    does not work in this situation, because _WIN32_WINNT is not defined
    in test program, and so <thread> seems to be fine.

    This patch is an attempt to fix the problem, by using the same setting
    for _WIN32_WINNT at configure time as is used at build time.

    I don't have access to one of the older systems so I don't think I can
    truly test this.  I did do a mingw cross build, though.  I'm going to
    ask the bug reporter to test it.

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

    (cherry picked from commit 2124b2de4bba05063218501dcccfc4cffe648cda)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |13.1
         Resolution|---                         |FIXED

--- Comment #34 from Tom Tromey <tromey at sourceware dot org> ---
We agreed to backport.
I think the gdb side of this is done.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #35 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #34)
> We agreed to backport.
> I think the gdb side of this is done.

No this problem is NOT fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

cqwrteur <euloanty at live dot com> changed:

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

--- Comment #36 from cqwrteur <euloanty at live dot com> ---
This issue still exists.

/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:150:7:
error: '__gthread_cond_init_function' was not declared in this scope; did you
mean '__gthread_mutex_init_function'?
  150 |       __GTHREAD_COND_INIT_FUNCTION(&_M_cond);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/sysdep.h:114:20: warning:
too many arguments for format [-Wformat-extra-args]
  114 | # define _(String) (String)
      |                    ^~~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/readelf.c:21891:17: note:
in expansion of macro '_'
21891 |           warn (_("note with invalid namesz and/or descsz found at
offset %#tx\n"),
      |                 ^
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/readelf.c: In function
'process_v850_notes':
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/sysdep.h:114:20: warning:
unknown conversion type character 't' in format [-Wformat=]
  114 | # define _(String) (String)
      |                    ^~~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/readelf.c:22004:17: note:
in expansion of macro '_'
22004 |           warn (_("corrupt descsz found in note at offset %#tx\n"),
      |                 ^
/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:156:69:
error: '_M_cond' was not declared in this scope
  156 |       int __e __attribute__((__unused__)) =
__gthread_cond_destroy(&_M_cond);
      |                                                                    
^~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/sysdep.h:114:20: warning:
too many arguments for format [-Wformat-extra-args]
  114 | # define _(String) (String)
      |                    ^~~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/readelf.c:22004:17: note:
in expansion of macro '_'
22004 |           warn (_("corrupt descsz found in note at offset %#tx\n"),
      |                 ^
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/sysdep.h:114:20: warning:
unknown conversion type character 'z' in format [-Wformat=]
  114 | # define _(String) (String)
      |                    ^~~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/readelf.c:22017:17: note:
in expansion of macro '_'
22017 |           warn (_("corrupt namesz found in note at offset %#zx\n"),
      |                 ^
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/sysdep.h:114:20: warning:
too many arguments for format [-Wformat-extra-args]
  114 | # define _(String) (String)
      |                    ^~~~~~~~
/home/cqwrteur/toolchains_build/binutils-gdb/binutils/readelf.c:22017:17: note:
in expansion of macro '_'
22017 |           warn (_("corrupt namesz found in note at offset %#zx\n"),
      |                 ^
/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:156:45:
error: '__gthread_cond_destroy' was not declared in this scope; did you mean
'__gthread_mutex_destroy'?
  156 |       int __e __attribute__((__unused__)) =
__gthread_cond_destroy(&_M_cond);
      |                                             ^~~~~~~~~~~~~~~~~~~~~~
      |                                             __gthread_mutex_destroy
  CCLD     bfdtest1.exe
  CCLD     bfdtest2.exe

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #37 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
It doesn't work because libstdc++ does not support the win32 thread model on
old versions of Windows. There's nothing GDB can do about that.

Build a mingw cross compiler with --disable-threads if you want to compile for
winxp and are happy to have no std::thread etc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #38 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #35)
> (In reply to Tom Tromey from comment #34)
> > We agreed to backport.
> > I think the gdb side of this is done.
> 
> No this problem is NOT fixed.

If you can think of some change gdb can make that will fix it,
I'm all ears.

My understanding is:

* gdb configure should now correctly detect that threads aren't supported,
but...
* ... there's still a libstdc++ buglet to be addressed in this area

Let me know what you think.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #39 from cqwrteur <euloanty at live dot com> ---
Yes. I think “gdb configure should now correctly detect that threads aren't
supported”

Because libstdc++ clearly does not want to fix the problem.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: tromey at sourceware dot org<mailto:sourceware-bugzilla@sourceware.org>
Sent: Friday, January 13, 2023 14:12
To: euloanty@live.com<mailto:euloanty@live.com>
Subject: [Bug build/29966] Cannot build anymore for win32 thread model of gdb

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

--- Comment #38 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #35)
> (In reply to Tom Tromey from comment #34)
> > We agreed to backport.
> > I think the gdb side of this is done.
>
> No this problem is NOT fixed.

If you can think of some change gdb can make that will fix it,
I'm all ears.

My understanding is:

* gdb configure should now correctly detect that threads aren't supported,
but...
* ... there's still a libstdc++ buglet to be addressed in this area

Let me know what you think.

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #40 from Tom Tromey <tromey at sourceware dot org> ---
> Yes. I think “gdb configure should now correctly detect that threads aren't
> supported”

Ok.  Do you know how to do that?
At this point, I don't.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #41 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #40)
> > Yes. I think “gdb configure should now correctly detect that threads aren't
> > supported”
> 
> Ok.  Do you know how to do that?
> At this point, I don't.

https://github.com/gcc-mirror/gcc/blob/6071e495e5802a8949d2b02df6aa31a5f40f2af9/libgcc/config/i386/gthr-win32.h#L66

You can detect include <bits/gthr-default.h> with __GTHREAD_HAS_COND macro

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[brobecker at gnat dot com]

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

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brobecker at gnat dot com

--- Comment #42 from Joel Brobecker <brobecker at gnat dot com> ---
Hi guys,

What's the impact of this issue? Is it limited to people trying to build GDB on
old versions of Windows, or it is affecting more situations?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[brobecker at gnat dot com]

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

--- Comment #43 from Joel Brobecker <brobecker at gnat dot com> ---
Maybe I'll amend:

Does it impact people trying to build a recent GDB using a recent GCC on old
versions of Windows (versions that would be older than Windows Vista)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #44 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Joel Brobecker from comment #43)
> Maybe I'll amend:
> 
> Does it impact people trying to build a recent GDB using a recent GCC on old
> versions of Windows (versions that would be older than Windows Vista)?

Yes, but the IIUC there is an additional fix in upstream libstdc++
that is planned to be fixed.  So it affects a small segment of
users at present: people building gdb on an old windows with
a gcc from git.  (That's my understanding anyway)

I tend to think this bug can be closed again.

(In reply to cqwrteur from comment #41)

> You can detect include <bits/gthr-default.h> with __GTHREAD_HAS_COND macro

I'd rather gdb not rely on libstdc++ internals.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #45 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to Tom Tromey from comment #44)
> Yes, but the IIUC there is an additional fix in upstream libstdc++
> that is planned to be fixed.

No, I've decided against it, because it gets ugly, and I have better things to
do than try to fix systems that were already EOL when I last used Windows
myself (which is a *long* time ago).

Libstdc++ is just going to officially and explicitly say that prehistoric
versions of Windows are not supported when using the win32 thread model. Either
use the posix thread model (which makes use of winpthreads), or build for
non-prehistoric versions.

So that might mean that GDB needs to pick a newer default value of
_WIN32_WINNT, because the current "define it to 0x0501 if not defined already"
logic selects a prehistoric version which cannot be used with GCC 13 +
--enable-threads=win32

Sorry, but libstdc++ progress is not going to be held back by a tiny handful of
vocal users that aren't actually helping provide support for their dead
targets.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #46 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to Jonathan Wakely from comment #45)
> So that might mean that GDB needs to pick a newer default value of
> _WIN32_WINNT, because the current "define it to 0x0501 if not defined
> already" logic selects a prehistoric version which cannot be used with GCC
> 13 + --enable-threads=win32

Another option (which I haven't actually tested) would be to extend the
existing configure check that uses std::thread to also include <mutex> and do:

std::mutex m;
std::lock_guard<std::mutex> l(m);

That would fail with GCC 13 + threads=win32 when _WIN32_WINNT < 0x0600, and so
GDB would disable threads.

It would work with GCC 13 with threads=posix, or threads=win32 && _WIN32_WINNT
>= 0x0600

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #47 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
Created attachment 14598
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14598&action=edit
Test std::mutex as well as std::thread in gdbsupport

Completely untested patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #48 from Tom Tromey <tromey at sourceware dot org> ---
To the OP - can you test Jonathan's patch?
If it works for you, we can apply it.
There's still time to get this in gdb 13 if you can test it
reasonably soon.  Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #49 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #48)
> To the OP - can you test Jonathan's patch?
> If it works for you, we can apply it.
> There's still time to get this in gdb 13 if you can test it
> reasonably soon.  Thanks.

hello. can you first fix this issue?

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

I cannot test anything due to this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #50 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #49)

> hello. can you first fix this issue?
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29973
> 
> I cannot test anything due to this bug.

Sorry, I have no idea about that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #51 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to cqwrteur from comment #49)
> I cannot test anything due to this bug.

Why can't you just use an older binutils version?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

--- Comment #52 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
I think unless OP starts being helpful this should just be closed. We don't
have enough info to even reproduce the issue.

I've built GCC trunk with --target=x86_64-w64-mingw32 --enable-threads=win32
and I can then build GDB with --target=x86_64-w64-mingw32
--host=x86_64-w64-mingw32. This works fine.

Adding CXXFLAGS=-D_WIN32_WINNT=0x0501 to the GDB flags fails, but not in any
way related to this bug:

make[5]: Entering directory '/tmp/gdb-win32/gnulib/import'
  CC       libgnu_a-closedir.o
/home/jwakely/src/binutils-gdb/gnulib/import/closedir.c: In function
'closedir':
/home/jwakely/src/binutils-gdb/gnulib/import/closedir.c:58:11: error: 'DIR' has
no member named 'current'
   58 |   if (dirp->current != INVALID_HANDLE_VALUE)
      |           ^~
/home/jwakely/src/binutils-gdb/gnulib/import/closedir.c:59:20: error: 'DIR' has
no member named 'current'
   59 |     FindClose (dirp->current);
      |                    ^~
make[5]: *** [Makefile:2632: libgnu_a-closedir.o] Error 1


So without more information to be able to reproduce OP's problem, this should
be closed IMHO.

For that failing build, without the patch in comment 47 gdbsupport/config.log
shows:

configure:8963: checking for std::thread
configure:8990: x86_64-w64-mingw32-g++ -c -pthread -D_WIN32_WINNT=0x0501   
conftest.cpp >&5
configure:8990: $? = 0
configure:8997: result: yes


With the patch it shows:

configure:8963: checking for std::thread and std::mutex
configure:8993: x86_64-w64-mingw32-g++ -c -pthread -D_WIN32_WINNT=0x0501   
conftest.cpp >&5
In file included from /home/jwakely/gcc/mingw-win32/include/c++/mutex:45,
                 from conftest.cpp:67:
/home/jwakely/gcc/mingw-win32/include/c++/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/jwakely/gcc/mingw-win32/include/c++/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/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h: In constructor
'std::__condvar::__condvar()':
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:151:37: error:
'_M_cond' was not declared in this scope
  151 |       __GTHREAD_COND_INIT_FUNCTION(&_M_cond);
      |                                     ^~~~~~~
In file included from
/home/jwakely/gcc/mingw-win32/include/c++/x86_64-w64-mingw32/bits/gthr.h:148,
                 from
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_thread.h:46,
                 from /home/jwakely/gcc/mingw-win32/include/c++/thread:45,
                 from conftest.cpp:66:
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:151:7: error:
'__gthread_cond_init_function' was not declared in this scope; did you mean
'__gthread_mutex_init_function'?
  151 |       __GTHREAD_COND_INIT_FUNCTION(&_M_cond);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h: In destructor
'std::__condvar::~__condvar()':
/home/jwakely/gcc/mingw-win32/include/c++/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/jwakely/gcc/mingw-win32/include/c++/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
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h: In member function
'void std::__condvar::wait(std::mutex&)':
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:171:32: error:
'_M_cond' was not declared in this scope
  171 |         = __gthread_cond_wait(&_M_cond, __m.native_handle());
      |                                ^~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:171:11: error:
'__gthread_cond_wait' was not declared in this scope; did you mean
'__gthread_once_t'?
  171 |         = __gthread_cond_wait(&_M_cond, __m.native_handle());
      |           ^~~~~~~~~~~~~~~~~~~
      |           __gthread_once_t
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h: In member function
'void std::__condvar::wait_until(std::mutex&, timespec&)':
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:178:33: error:
'_M_cond' was not declared in this scope
  178 |       __gthread_cond_timedwait(&_M_cond, __m.native_handle(),
&__abs_time);
      |                                 ^~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:178:7: error:
'__gthread_cond_timedwait' was not declared in this scope
  178 |       __gthread_cond_timedwait(&_M_cond, __m.native_handle(),
&__abs_time);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h: In member function
'void std::__condvar::notify_one()':
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:193:68: error:
'_M_cond' was not declared in this scope
  193 |       int __e __attribute__((__unused__)) =
__gthread_cond_signal(&_M_cond);
      |                                                                   
^~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:193:45: error:
'__gthread_cond_signal' was not declared in this scope
  193 |       int __e __attribute__((__unused__)) =
__gthread_cond_signal(&_M_cond);
      |                                             ^~~~~~~~~~~~~~~~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h: In member function
'void std::__condvar::notify_all()':
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:200:71: error:
'_M_cond' was not declared in this scope
  200 |       int __e __attribute__((__unused__)) =
__gthread_cond_broadcast(&_M_cond);
      |                                                                      
^~~~~~~
/home/jwakely/gcc/mingw-win32/include/c++/bits/std_mutex.h:200:45: error:
'__gthread_cond_broadcast' was not declared in this scope
  200 |       int __e __attribute__((__unused__)) =
__gthread_cond_broadcast(&_M_cond);
      |                                             ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/jwakely/gcc/mingw-win32/include/c++/mutex:48:
/home/jwakely/gcc/mingw-win32/include/c++/condition_variable: At global scope:
/home/jwakely/gcc/mingw-win32/include/c++/condition_variable:83:13: error:
'__gthread_cond_t' does not name a type; did you mean '__gthread_once_t'?
   83 |     typedef __gthread_cond_t*           native_handle_type;
      |             ^~~~~~~~~~~~~~~~
      |             __gthread_once_t
/home/jwakely/gcc/mingw-win32/include/c++/condition_variable:183:5: error:
'native_handle_type' does not name a type
  183 |     native_handle_type
      |     ^~~~~~~~~~~~~~~~~~
conftest.cpp: In function 'int main()':
conftest.cpp:74:10: error: 'local_guard' is not a member of 'std'; did you mean
'lock_guard'?
   74 |     std::local_guard<std::mutex> l(m);
      |          ^~~~~~~~~~~
      |          lock_guard
conftest.cpp:74:32: error: expected primary-expression before '>' token
   74 |     std::local_guard<std::mutex> l(m);
      |                                ^
conftest.cpp:74:34: error: 'l' was not declared in this scope
   74 |     std::local_guard<std::mutex> l(m);
      |                                  ^
configure:8993: $? = 1
configure: failed program was:

...

configure:9000: result: no

So the error is pretty ugly, but gdbsupport/configure correctly detects that
std::thread and std::mutex cannot be used when -D_WIN32_WINNT=0x0501 is used.

But with or without the patch, libiberty fails when using -D_WIN32_WINNT=0x0501
so OP must be doing something that he's not showing. And that's just wasting
everybody's time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #53 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Jonathan Wakely from comment #52)
> I think unless OP starts being helpful this should just be closed. We don't
> have enough info to even reproduce the issue.

> For that failing build, without the patch in comment 47
> gdbsupport/config.log shows:

> So the error is pretty ugly, but gdbsupport/configure correctly detects that
> std::thread and std::mutex cannot be used when -D_WIN32_WINNT=0x0501 is used.
> 
> But with or without the patch, libiberty fails when using
> -D_WIN32_WINNT=0x0501 so OP must be doing something that he's not showing.
> And that's just wasting everybody's time.

I tend to agree.
OP, can you try an older binutils?
Otherwise I plan to close this bug and leave the code as-is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #54 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #53)
> (In reply to Jonathan Wakely from comment #52)
> > I think unless OP starts being helpful this should just be closed. We don't
> > have enough info to even reproduce the issue.
> 
> > For that failing build, without the patch in comment 47
> > gdbsupport/config.log shows:
> 
> > So the error is pretty ugly, but gdbsupport/configure correctly detects that
> > std::thread and std::mutex cannot be used when -D_WIN32_WINNT=0x0501 is used.
> > 
> > But with or without the patch, libiberty fails when using
> > -D_WIN32_WINNT=0x0501 so OP must be doing something that he's not showing.
> > And that's just wasting everybody's time.
> 
> I tend to agree.
> OP, can you try an older binutils?
> Otherwise I plan to close this bug and leave the code as-is.

i am not wasting anyone's time. I am just building the binutils-gdb with the
default settings.

NONONONOONONONONONONONONONON

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #55 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #53)
> (In reply to Jonathan Wakely from comment #52)
> > I think unless OP starts being helpful this should just be closed. We don't
> > have enough info to even reproduce the issue.
> 
> > For that failing build, without the patch in comment 47
> > gdbsupport/config.log shows:
> 
> > So the error is pretty ugly, but gdbsupport/configure correctly detects that
> > std::thread and std::mutex cannot be used when -D_WIN32_WINNT=0x0501 is used.
> > 
> > But with or without the patch, libiberty fails when using
> > -D_WIN32_WINNT=0x0501 so OP must be doing something that he's not showing.
> > And that's just wasting everybody's time.
> 
> I tend to agree.
> OP, can you try an older binutils?
> Otherwise I plan to close this bug and leave the code as-is.

He is wrong

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #56 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #55)
> (In reply to Tom Tromey from comment #53)
> > (In reply to Jonathan Wakely from comment #52)
> > > I think unless OP starts being helpful this should just be closed. We don't
> > > have enough info to even reproduce the issue.
> > 
> > > For that failing build, without the patch in comment 47
> > > gdbsupport/config.log shows:
> > 
> > > So the error is pretty ugly, but gdbsupport/configure correctly detects that
> > > std::thread and std::mutex cannot be used when -D_WIN32_WINNT=0x0501 is used.
> > > 
> > > But with or without the patch, libiberty fails when using
> > > -D_WIN32_WINNT=0x0501 so OP must be doing something that he's not showing.
> > > And that's just wasting everybody's time.
> > 
> > I tend to agree.
> > OP, can you try an older binutils?
> > Otherwise I plan to close this bug and leave the code as-is.
> 
> He is wrong

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

I find quite funny why libstdc++ refuses to fix this issue first.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #57 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #56)
> (In reply to cqwrteur from comment #55)
> > (In reply to Tom Tromey from comment #53)
> > > (In reply to Jonathan Wakely from comment #52)
> > > > I think unless OP starts being helpful this should just be closed. We don't
> > > > have enough info to even reproduce the issue.
> > > 
> > > > For that failing build, without the patch in comment 47
> > > > gdbsupport/config.log shows:
> > > 
> > > > So the error is pretty ugly, but gdbsupport/configure correctly detects that
> > > > std::thread and std::mutex cannot be used when -D_WIN32_WINNT=0x0501 is used.
> > > > 
> > > > But with or without the patch, libiberty fails when using
> > > > -D_WIN32_WINNT=0x0501 so OP must be doing something that he's not showing.
> > > > And that's just wasting everybody's time.
> > > 
> > > I tend to agree.
> > > OP, can you try an older binutils?
> > > Otherwise I plan to close this bug and leave the code as-is.
> > 
> > He is wrong
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=29973
> 
> I find quite funny why libstdc++ refuses to fix this issue first.

jwakely it is all your fault.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[jwakely.gcc at gmail dot com]

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

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jwakely.gcc at gmail dot com       |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #58 from Mark Wielaard <mark at klomp dot org> ---
(In reply to cqwrteur from comment #54)
> i am not wasting anyone's time. I am just building the binutils-gdb with the
> default settings.
> 
> NONONONOONONONONONONONONONON

> He is wrong

> I find quite funny why libstdc++ refuses to fix this [binutils] issue first.

> jwakely it is all your fault.

You are wasting people's time, posting nonsense, not providing information
people ask for to help you and attack other people. Not just in this bug but in
others. You have to immediately stop doing that or your will be blocked from
participating in bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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

--- Comment #59 from Tom Tromey <tromey at sourceware dot org> ---
Closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

cqwrteur <euloanty at live dot com> changed:

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

--- Comment #60 from cqwrteur <euloanty at live dot com> ---
(In reply to Tom Tromey from comment #59)
> Closing.

I am not doing anything wrong. But jwakely just said I did crazy things, which
is false.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #61 from cqwrteur <euloanty at live dot com> ---
(In reply to Mark Wielaard from comment #58)
> (In reply to cqwrteur from comment #54)
> > i am not wasting anyone's time. I am just building the binutils-gdb with the
> > default settings.
> > 
> > NONONONOONONONONONONONONONON
> 
> > He is wrong
> 
> > I find quite funny why libstdc++ refuses to fix this [binutils] issue first.
> 
> > jwakely it is all your fault.
> 
> You are wasting people's time, posting nonsense, not providing information
> people ask for to help you and attack other people. Not just in this bug but
> in others. You have to immediately stop doing that or your will be blocked
> from participating in bugzilla.

I am not wasting people's time. I think the issue comes with libstdc++'s recent
changes to threading and tz etc. However, he refuses to help investigate the
issue. I cannot test the patch because I could not bootstrap a toolchain any
more due to the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #62 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #61)
> (In reply to Mark Wielaard from comment #58)
> > (In reply to cqwrteur from comment #54)
> > > i am not wasting anyone's time. I am just building the binutils-gdb with the
> > > default settings.
> > > 
> > > NONONONOONONONONONONONONONON
> > 
> > > He is wrong
> > 
> > > I find quite funny why libstdc++ refuses to fix this [binutils] issue first.
> > 
> > > jwakely it is all your fault.
> > 
> > You are wasting people's time, posting nonsense, not providing information
> > people ask for to help you and attack other people. Not just in this bug but
> > in others. You have to immediately stop doing that or your will be blocked
> > from participating in bugzilla.
> 
> I am not wasting people's time. I think the issue comes with libstdc++'s
> recent changes to threading and tz etc. However, he refuses to help
> investigate the issue. I cannot test the patch because I could not bootstrap
> a toolchain any more due to the bug.

But with or without the patch, libiberty fails when using -D_WIN32_WINNT=0x0501
so OP must be doing something that he's not showing. And that's just wasting
everybody's time.

I did not set anything. Here is my build script for example. You can try this
build script yourself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[euloanty at live dot com]

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

--- Comment #63 from cqwrteur <euloanty at live dot com> ---
Created attachment 14639
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14639&action=edit
My build script.

You can check and tell what craziness I did. I added no flags.

I do not even know why GDB sets up -the D_WIN32_WINNT macro. It just should
not.

Here is the build script that will create both cross and Canadian toolchain of
GCC 13.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[brobecker at gnat dot com]

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

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|brobecker at gnat dot com          |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

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

--- Comment #64 from Mark Wielaard <mark at klomp dot org> ---
(In reply to cqwrteur from comment #60)
> (In reply to Tom Tromey from comment #59)
> > Closing.
> 
> I am not doing anything wrong. But jwakely just said I did crazy things,
> which is false.

Don't reopen bugs just because you don't agree with the technical solution. And
stop attacking developers who simply request you provide information about your
setup. This is your last warning.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/29966] Cannot build anymore for win32 thread model of gdb

[tromey at sourceware dot org]

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

--- Comment #65 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to cqwrteur from comment #60)
> (In reply to Tom Tromey from comment #59)
> > Closing.
> 
> I am not doing anything wrong. But jwakely just said I did crazy things,
> which is false.

I'd like to ask you to seriously re-read comments 54, 55, and 56 again.
Try to read them as if you are a maintainer and someone is writing that
stuff to you.

I feel like we've been quite patient.  A 60+ message thread should
be more than sufficient to resolve this issue.

If you can try a working binutils, I'll even give you a second shot.
But you should be aware, you've burnt a lot of good will.  We all
have a lot of other things to do.  You can already see others
(understandably) removing themselves from the CC.

-- 
You are receiving this mail because:
You are on the CC list for the bug.