Recently gcc added some changes to win32 thread model https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
We need more information to understand the problem. At the very least the failing compilation and error messages would be good.
Created attachment 14562 [details] config
Created attachment 14563 [details] err
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.
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.
(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.
(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.
(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++.
(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.
Created attachment 14564 [details] all logs in gdbsupport
(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.
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.
(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?
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.
(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.
(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.
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.
(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.
Could you please try this patch? https://sourceware.org/pipermail/gdb-patches/2023-January/195484.html
(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
(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.
(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.
(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
That looks completely unrelated.
(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.
(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
(In reply to cqwrteur from comment #26) > not working Can you send gdbsupport/config.log? That's the important part.
Created attachment 14573 [details] log file log
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.
Jonathan pointed out the proposed libstdc++ fix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225#c23
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
I'm going to leave this open while we ponder whether to put it on the GDB 13 branch.
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)
We agreed to backport. I think the gdb side of this is done.
(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.
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
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.
(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.
Created attachment 14591 [details] attachment-584356-0.html 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.
> 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.
(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
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?
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)?
(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.
(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.
(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
Created attachment 14598 [details] Test std::mutex as well as std::thread in gdbsupport Completely untested patch.
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.
(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.
(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.
(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?
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.
(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.
(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
(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
(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.
(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.
(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.
Closing.
(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.
(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.
(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.
Created attachment 14639 [details] 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.
(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.
(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.