* [PATCH] Fix build issues with mingw toolchain @ 2024-05-06 5:58 Bernd Edlinger 2024-05-06 14:57 ` Tom Tromey 0 siblings, 1 reply; 25+ messages in thread From: Bernd Edlinger @ 2024-05-06 5:58 UTC (permalink / raw) To: gdb-patches With a x86_64-pc-mingw32 toolchain there is a build issue whether or not the --disable-threading option is used. The problem happens because _WIN32_WINNT is defined to 0x501 before #include <mutex> which makes the compilation abort due to missing support for __gthread_cond_t in std_mutex.h, which is conditional on _WIN32_WINNT >= 0x600. Fix the case when --disable-threading is used, by only including <mutex> in gdb/complaints.c when STD_CXX_THREAD is defined. Additionally make the configure script try to #include <mutex> to automatically select --disable-threading when the header file is not able to compile. --- gdb/complaints.c | 2 ++ gdb/configure | 1 + gdbserver/configure | 1 + gdbsupport/common.m4 | 1 + gdbsupport/configure | 1 + 5 files changed, 6 insertions(+) diff --git a/gdb/complaints.c b/gdb/complaints.c index debafde794b..07c0f7e52e5 100644 --- a/gdb/complaints.c +++ b/gdb/complaints.c @@ -24,7 +24,9 @@ #include "top.h" #include "gdbsupport/selftest.h" #include <unordered_map> +#if CXX_STD_THREAD #include <mutex> +#endif /* Map format strings to counters. */ diff --git a/gdb/configure b/gdb/configure index c3d5cf7ed63..98cd488a737 100755 --- a/gdb/configure +++ b/gdb/configure @@ -20854,6 +20854,7 @@ else # endif #endif /* __MINGW32__ || __CYGWIN__ */ #include <thread> + #include <mutex> void callback() { } int main () diff --git a/gdbserver/configure b/gdbserver/configure index 026d250cc73..2da525ebf3b 100755 --- a/gdbserver/configure +++ b/gdbserver/configure @@ -9561,6 +9561,7 @@ else # endif #endif /* __MINGW32__ || __CYGWIN__ */ #include <thread> + #include <mutex> void callback() { } int main () diff --git a/gdbsupport/common.m4 b/gdbsupport/common.m4 index 240ec008f2a..bef396445ba 100644 --- a/gdbsupport/common.m4 +++ b/gdbsupport/common.m4 @@ -114,6 +114,7 @@ AC_DEFUN([GDB_AC_COMMON], [ # endif #endif /* __MINGW32__ || __CYGWIN__ */ #include <thread> + #include <mutex> void callback() { }]], [[std::thread t(callback);]])], gdb_cv_cxx_std_thread=yes, diff --git a/gdbsupport/configure b/gdbsupport/configure index ae991250ce4..a218b06ce28 100755 --- a/gdbsupport/configure +++ b/gdbsupport/configure @@ -12335,6 +12335,7 @@ else # endif #endif /* __MINGW32__ || __CYGWIN__ */ #include <thread> + #include <mutex> void callback() { } int main () -- 2.39.2 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-06 5:58 [PATCH] Fix build issues with mingw toolchain Bernd Edlinger @ 2024-05-06 14:57 ` Tom Tromey 2024-05-06 17:09 ` Bernd Edlinger 0 siblings, 1 reply; 25+ messages in thread From: Tom Tromey @ 2024-05-06 14:57 UTC (permalink / raw) To: Bernd Edlinger; +Cc: gdb-patches >>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes: Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue Bernd> whether or not the --disable-threading option is used. Bernd> The problem happens because _WIN32_WINNT is defined to 0x501 Bernd> before #include <mutex> which makes the compilation abort Bernd> due to missing support for __gthread_cond_t in std_mutex.h, Bernd> which is conditional on _WIN32_WINNT >= 0x600. Bernd> Fix the case when --disable-threading is used, by only Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD Bernd> is defined. Bernd> Additionally make the configure script try to #include <mutex> Bernd> to automatically select --disable-threading when the header file Bernd> is not able to compile. This looks reasonable to me. Thank you. Approved-By: Tom Tromey <tom@tromey.com> I wonder if we could change _WIN32_WINNT when threading is enabled, so the new gcc support could be used. Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-06 14:57 ` Tom Tromey @ 2024-05-06 17:09 ` Bernd Edlinger 2024-05-06 20:18 ` Tom Tromey 2024-05-10 17:37 ` Eli Zaretskii 0 siblings, 2 replies; 25+ messages in thread From: Bernd Edlinger @ 2024-05-06 17:09 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches On 5/6/24 16:57, Tom Tromey wrote: >>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes: > > Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue > Bernd> whether or not the --disable-threading option is used. > Bernd> The problem happens because _WIN32_WINNT is defined to 0x501 > Bernd> before #include <mutex> which makes the compilation abort > Bernd> due to missing support for __gthread_cond_t in std_mutex.h, > Bernd> which is conditional on _WIN32_WINNT >= 0x600. > > Bernd> Fix the case when --disable-threading is used, by only > Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD > Bernd> is defined. > > Bernd> Additionally make the configure script try to #include <mutex> > Bernd> to automatically select --disable-threading when the header file > Bernd> is not able to compile. > > This looks reasonable to me. Thank you. > Approved-By: Tom Tromey <tom@tromey.com> > Okay, pushed. > I wonder if we could change _WIN32_WINNT when threading is enabled, so > the new gcc support could be used. > frankly I don't understand at all why the _WIN32_WINNT is set to this specific value, and maybe that was a good idea when windows XP was the latest version. My feeling would be to remove that define all together. The code looks like its intention is to raise the _WIN32_WINNT from 4.x to 5.01, but instead it lowers the _WIN32_WINNT version from 10.0 to 5.01 at least with my toolchain, where this define is not a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>, but only if it is not fixed to something else. However I am not an expert in this area, and I have only tried this with my self-built cross-toolchain. What I can tell, is that although I have no working <pthread.h> in my sysroot, the std::thread implementation seems to work, as long as _WIN32_WINNT is set to something >= 0x0600. Thanks Bernd > Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-06 17:09 ` Bernd Edlinger @ 2024-05-06 20:18 ` Tom Tromey 2024-05-07 10:59 ` Hannes Domani 2024-05-10 17:39 ` Eli Zaretskii 2024-05-10 17:37 ` Eli Zaretskii 1 sibling, 2 replies; 25+ messages in thread From: Tom Tromey @ 2024-05-06 20:18 UTC (permalink / raw) To: Bernd Edlinger; +Cc: Tom Tromey, gdb-patches >>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes: >> I wonder if we could change _WIN32_WINNT when threading is enabled, so >> the new gcc support could be used. Bernd> frankly I don't understand at all why the _WIN32_WINNT is set to this Bernd> specific value, and maybe that was a good idea when windows XP was the Bernd> latest version. My feeling would be to remove that define all together. The addition itself seems to be commit 353ea2d1, which has some explanation. I gather the idea is that, this way, a gdb built on Windows will work all the way back to NT. I tried changing the value but Eli objected: https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html Internally at AdaCore we still have this part of the change installed, precisely to pick up the mingw threading support from gcc; plus we have no need for Windows XP. From https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle, I gather that XP is still in reasonably wide use. I'm not sure how many developers use it, though, or even if gdb actually does run there, not having access to such a machine myself. I'm sympathetic to changing this somehow but I don't know how to make progress on it. Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-06 20:18 ` Tom Tromey @ 2024-05-07 10:59 ` Hannes Domani 2024-05-10 17:24 ` Tom Tromey 2024-05-10 17:39 ` Eli Zaretskii 1 sibling, 1 reply; 25+ messages in thread From: Hannes Domani @ 2024-05-07 10:59 UTC (permalink / raw) To: Bernd Edlinger, Tom Tromey; +Cc: gdb-patches Am Montag, 6. Mai 2024 um 22:18:50 MESZ hat Tom Tromey <tromey@adacore.com> Folgendes geschrieben: > >>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes: > > >> I wonder if we could change _WIN32_WINNT when threading is enabled, so > >> the new gcc support could be used. > > Bernd> frankly I don't understand at all why the _WIN32_WINNT is set to this > Bernd> specific value, and maybe that was a good idea when windows XP was the > Bernd> latest version. My feeling would be to remove that define all together. > > The addition itself seems to be commit 353ea2d1, which has some > explanation. I gather the idea is that, this way, a gdb built on > Windows will work all the way back to NT. > > I tried changing the value but Eli objected: > > https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html > > Internally at AdaCore we still have this part of the change installed, > precisely to pick up the mingw threading support from gcc; plus we have > no need for Windows XP. > > From https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle, I > gather that XP is still in reasonably wide use. I'm not sure how many > developers use it, though, or even if gdb actually does run there, not > having access to such a machine myself. > > I'm sympathetic to changing this somehow but I don't know how to make > progress on it. Coincidentally I installed XP on a VM last week, because I was also curious if my gdb-14.2 build works there, and it does. If you don't need XP support, can't you just define _WIN32_WINNT in CPPFLAGS? Hannes ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-07 10:59 ` Hannes Domani @ 2024-05-10 17:24 ` Tom Tromey 2024-05-10 17:32 ` Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 25+ messages in thread From: Tom Tromey @ 2024-05-10 17:24 UTC (permalink / raw) To: Hannes Domani; +Cc: Bernd Edlinger, Tom Tromey, gdb-patches >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: Hannes> If you don't need XP support, can't you just define _WIN32_WINNT Hannes> in CPPFLAGS? Yeah, it seems possible. Maybe the problem is that unless you remember this (it seems pretty obscure), a mingw build with a newer version of GCC is going to fail due to libstdc++ wanting an older version that gdb's default. Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 17:24 ` Tom Tromey @ 2024-05-10 17:32 ` Eli Zaretskii 2024-05-10 17:41 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2024-05-10 17:32 UTC (permalink / raw) To: Tom Tromey; +Cc: ssbssa, bernd.edlinger, tromey, gdb-patches > From: Tom Tromey <tromey@adacore.com> > Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>, Tom Tromey > <tromey@adacore.com>, "gdb-patches@sourceware.org" > <gdb-patches@sourceware.org> > Date: Fri, 10 May 2024 11:24:18 -0600 > > >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: > > Hannes> If you don't need XP support, can't you just define _WIN32_WINNT > Hannes> in CPPFLAGS? > > Yeah, it seems possible. It's possible, but it doesn't solve the problem, IME. _WIN32_WINNT is a compile-time measure, intended to make sure that if you target your program to versions of Windows >= N, running the program on older versions will likely emit an error popup, and Windows will refuse to run the program. This is not what we want here: we do want to support versions of Windows older than 10. > Maybe the problem is that unless you remember > this (it seems pretty obscure), a mingw build with a newer version of > GCC is going to fail due to libstdc++ wanting an older version that > gdb's default. That is another problem with setting _WIN32_WINNT too high, yes. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 17:24 ` Tom Tromey 2024-05-10 17:32 ` Eli Zaretskii @ 2024-05-10 17:41 ` Eli Zaretskii 2024-05-10 19:03 ` Pedro Alves 2024-05-11 10:55 ` Hannes Domani 3 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2024-05-10 17:41 UTC (permalink / raw) To: Tom Tromey; +Cc: ssbssa, bernd.edlinger, gdb-patches > From: Tom Tromey <tromey@adacore.com> > Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>, Tom Tromey > <tromey@adacore.com>, "gdb-patches@sourceware.org" > <gdb-patches@sourceware.org> > Date: Fri, 10 May 2024 11:24:18 -0600 > X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, > DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, > SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 > > >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: > > Hannes> If you don't need XP support, can't you just define _WIN32_WINNT > Hannes> in CPPFLAGS? > > Yeah, it seems possible. Maybe the problem is that unless you remember > this (it seems pretty obscure), a mingw build with a newer version of > GCC is going to fail due to libstdc++ wanting an older version that > gdb's default. That wasn't supposed to happen, if the system headers define _WIN32_WINNT to a higher value than 0x0501. Something is wrong, and we should figure out what and why. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 17:24 ` Tom Tromey 2024-05-10 17:32 ` Eli Zaretskii 2024-05-10 17:41 ` Eli Zaretskii @ 2024-05-10 19:03 ` Pedro Alves 2024-05-11 6:20 ` Eli Zaretskii 2024-05-11 10:55 ` Hannes Domani 3 siblings, 1 reply; 25+ messages in thread From: Pedro Alves @ 2024-05-10 19:03 UTC (permalink / raw) To: Tom Tromey, Hannes Domani; +Cc: Bernd Edlinger, gdb-patches On 2024-05-10 18:24, Tom Tromey wrote: >>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: > > Hannes> If you don't need XP support, can't you just define _WIN32_WINNT > Hannes> in CPPFLAGS? > > Yeah, it seems possible. Maybe the problem is that unless you remember > this (it seems pretty obscure), a mingw build with a newer version of > GCC is going to fail due to libstdc++ wanting an older version that > gdb's default. Presumably, if you pass --enable-threading=yes, but then configure detects threading can't work, the configure fails. We could at least make the error mention that you need to set _WIN32_WINNT to at least 0x600 in CFLAGS. FWIW, I looked at this a while ago, and saw that Cygwin's oldest supported version is Windows 8.1 (says so at https://www.cygwin.com/). Many people using Windows gdb will use a Cygwin environment, or Msys2 (which is a Cygwin fork), or "git bash" (which is an Msys2 fork...), and those won't work on older Windows. It's quite likely that number of people really really using current GDB (for anything productive) on older Windows versions is very reduced, if not approaching zero. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 19:03 ` Pedro Alves @ 2024-05-11 6:20 ` Eli Zaretskii 2024-05-13 14:21 ` Pedro Alves 0 siblings, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2024-05-11 6:20 UTC (permalink / raw) To: Pedro Alves; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches > Date: Fri, 10 May 2024 20:03:32 +0100 > Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>, > "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> > From: Pedro Alves <pedro@palves.net> > > On 2024-05-10 18:24, Tom Tromey wrote: > >>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: > > > > Hannes> If you don't need XP support, can't you just define _WIN32_WINNT > > Hannes> in CPPFLAGS? > > > > Yeah, it seems possible. Maybe the problem is that unless you remember > > this (it seems pretty obscure), a mingw build with a newer version of > > GCC is going to fail due to libstdc++ wanting an older version that > > gdb's default. > > Presumably, if you pass --enable-threading=yes, but then configure detects > threading can't work, the configure fails. We could at least make the > error mention that you need to set _WIN32_WINNT to at least 0x600 in CFLAGS. > > FWIW, I looked at this a while ago, and saw that Cygwin's oldest supported version > is Windows 8.1 (says so at https://www.cygwin.com/). > > Many people using Windows gdb will use a Cygwin environment, or Msys2 (which is > a Cygwin fork), or "git bash" (which is an Msys2 fork...), and those won't work > on older Windows. Cygwin and MSYS2 indeed won't run on older Windows, but programs they create still can, if built with caution and don't use any APIs from later versions without run-time checking (like we do). > It's quite likely that number of people really really using > current GDB (for anything productive) on older Windows versions is very reduced, > if not approaching zero. Emacs still supports Windows XP (and even older versions), so it is important for us to be able to run the latest GDB on XP. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-11 6:20 ` Eli Zaretskii @ 2024-05-13 14:21 ` Pedro Alves 2024-05-13 15:36 ` Eli Zaretskii 2024-05-13 18:45 ` Tom Tromey 0 siblings, 2 replies; 25+ messages in thread From: Pedro Alves @ 2024-05-13 14:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches Hi Eli, On 2024-05-11 07:20, Eli Zaretskii wrote: >> From: Pedro Alves <pedro@palves.net> > Cygwin and MSYS2 indeed won't run on older Windows, but programs they > create still can, if built with caution and don't use any APIs from > later versions without run-time checking (like we do). > >> It's quite likely that number of people really really using >> current GDB (for anything productive) on older Windows versions is very reduced, >> if not approaching zero. > > Emacs still supports Windows XP (and even older versions), so it is > important for us to be able to run the latest GDB on XP. > OOC, is there a reason GDB versions other than the latest wouldn't work for that? I don't plan on proposing bumping the minimal supported version currently, as I don't recall it blocking anything, but I would like to understand that constraint better, for if/when the time comes. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-13 14:21 ` Pedro Alves @ 2024-05-13 15:36 ` Eli Zaretskii 2024-05-13 17:12 ` Pedro Alves 2024-05-13 18:45 ` Tom Tromey 1 sibling, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2024-05-13 15:36 UTC (permalink / raw) To: Pedro Alves; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches > Date: Mon, 13 May 2024 15:21:16 +0100 > Cc: tromey@adacore.com, ssbssa@yahoo.de, bernd.edlinger@hotmail.de, > gdb-patches@sourceware.org > From: Pedro Alves <pedro@palves.net> > > On 2024-05-11 07:20, Eli Zaretskii wrote: > >> From: Pedro Alves <pedro@palves.net> > > > Cygwin and MSYS2 indeed won't run on older Windows, but programs they > > create still can, if built with caution and don't use any APIs from > > later versions without run-time checking (like we do). > > > >> It's quite likely that number of people really really using > >> current GDB (for anything productive) on older Windows versions is very reduced, > >> if not approaching zero. > > > > Emacs still supports Windows XP (and even older versions), so it is > > important for us to be able to run the latest GDB on XP. > > > > OOC, is there a reason GDB versions other than the latest wouldn't work for > that? Well, the future support for non-stop on Windows is one reason. Emacs on Windows uses several threads, as you may or may not know. Newer GCC versions used to compile Emacs are another reason: as DWARF info emitted by GCC is enhanced, we need newer versions of GDB to support that. More generally, as long as GDB doesn't _have_ to drop XP, i.e., as long as keeping it doesn't place a too significant burden on GDB maintenance, I think we should not deliberately break it. > I don't plan on proposing bumping the minimal supported version currently, > as I don't recall it blocking anything, but I would like to understand that > constraint better, for if/when the time comes. I hope I provided at least some rationale for my opinions. (They are not constraints, not unless the entire team agrees that this is our official policy.) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-13 15:36 ` Eli Zaretskii @ 2024-05-13 17:12 ` Pedro Alves 0 siblings, 0 replies; 25+ messages in thread From: Pedro Alves @ 2024-05-13 17:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches On 2024-05-13 16:36, Eli Zaretskii wrote: >> Date: Mon, 13 May 2024 15:21:16 +0100 >> Cc: tromey@adacore.com, ssbssa@yahoo.de, bernd.edlinger@hotmail.de, >> gdb-patches@sourceware.org >> From: Pedro Alves <pedro@palves.net> >> >> On 2024-05-11 07:20, Eli Zaretskii wrote: >>>> From: Pedro Alves <pedro@palves.net> >> >>> Cygwin and MSYS2 indeed won't run on older Windows, but programs they >>> create still can, if built with caution and don't use any APIs from >>> later versions without run-time checking (like we do). >>> >>>> It's quite likely that number of people really really using >>>> current GDB (for anything productive) on older Windows versions is very reduced, >>>> if not approaching zero. >>> >>> Emacs still supports Windows XP (and even older versions), so it is >>> important for us to be able to run the latest GDB on XP. >>> >> >> OOC, is there a reason GDB versions other than the latest wouldn't work for >> that? > > Well, the future support for non-stop on Windows is one reason. Emacs > on Windows uses several threads, as you may or may not know. That feature will only work on Windows 10 and above, so newer GDB will work the same as older GDB on WinXP. > > Newer GCC versions used to compile Emacs are another reason: as DWARF > info emitted by GCC is enhanced, we need newer versions of GDB to > support that. OK, I can see that. > > More generally, as long as GDB doesn't _have_ to drop XP, i.e., as > long as keeping it doesn't place a too significant burden on GDB > maintenance, I think we should not deliberately break it. Agreed. > >> I don't plan on proposing bumping the minimal supported version currently, >> as I don't recall it blocking anything, but I would like to understand that >> constraint better, for if/when the time comes. > > I hope I provided at least some rationale for my opinions. (They are > not constraints, not unless the entire team agrees that this is our > official policy.) > Thanks for the clarification. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-13 14:21 ` Pedro Alves 2024-05-13 15:36 ` Eli Zaretskii @ 2024-05-13 18:45 ` Tom Tromey 2024-05-14 14:20 ` Pedro Alves 1 sibling, 1 reply; 25+ messages in thread From: Tom Tromey @ 2024-05-13 18:45 UTC (permalink / raw) To: Pedro Alves; +Cc: Eli Zaretskii, tromey, ssbssa, bernd.edlinger, gdb-patches Pedro> I don't plan on proposing bumping the minimal supported version currently, Pedro> as I don't recall it blocking anything, but I would like to understand that Pedro> constraint better, for if/when the time comes. The problem is that libstdc++ puts gdb in a bind. On the one hand, gdb tries to support XP. On the other hand, <thread> requires a newer version; and use of threads is desirable. Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-13 18:45 ` Tom Tromey @ 2024-05-14 14:20 ` Pedro Alves 2024-05-14 17:02 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Pedro Alves @ 2024-05-14 14:20 UTC (permalink / raw) To: Tom Tromey; +Cc: Eli Zaretskii, ssbssa, bernd.edlinger, gdb-patches On 2024-05-13 19:45, Tom Tromey wrote: > Pedro> I don't plan on proposing bumping the minimal supported version currently, > Pedro> as I don't recall it blocking anything, but I would like to understand that > Pedro> constraint better, for if/when the time comes. > > The problem is that libstdc++ puts gdb in a bind. > > On the one hand, gdb tries to support XP. > On the other hand, <thread> requires a newer version; and use of threads > is desirable. That is for the win32 threading model, right? I just tried cross building a win32 mingw gdb using the posix thread model: /home/pedro/gdb/src/configure \ --disable-ld \ --disable-binutils \ --disable-gas \ --disable-gold \ --disable-nls \ --build=x86_64-pc-linux-gnu \ --host=i686-w64-mingw32 \ --target=i686-w64-mingw32 \ --disable-source-highlight \ --with-static-standard-libraries \ --with-gmp=/home/pedro/src/gmp/install-win32 \ --with-mpfr=/home/pedro/src/mpfr/install-win32 \ --with-expat=yes --with-libexpat-prefix=/home/pedro/src/expat/install-win32/ \ --enable-threading \ CC=i686-w64-mingw32-gcc-posix \ CXX=i686-w64-mingw32-g++-posix \ CFLAGS="-g3 -O0" \ CXXFLAGS="-g3 -O0" and I got: $ wine ./gdb -ex "maintenance show worker-threads" -q --batch The number of worker threads GDB can use is the default (currently 8). I think this binary would work on WinXP, and it supports threads. The 64-bit mingw gcc with win32 threading model that comes with Ubuntu 22.04 seems to be too old to support threading OOTB even if I configure with -D_WIN32_WINNT=0x600 in CFLAGS/CXXFLAGS. It's GCC 10 based. I think I'd need at least GCC 14. But I think you should be able to configure with --enable-threading CFLAGS="-D_WIN32_WINNT=0x600" CXXFLAGS="-D_WIN32_WINNT=0x600" and then threads will be enabled. If this doesn't work (with GCC >= 14), then it seems like a bug to me. Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread doesn't work. I think that's a bug. If I explicitly request threading, and then configure detects std::thread doesn't work, it should error out. Other options work that way, like e.g., the TUI checks for curses: # Check whether we should enable the TUI, but only do so if we really # can. if test x"$enable_tui" != xno; then if test "$curses_found" != no; then CONFIG_OBS="$CONFIG_OBS \$(SUBDIR_TUI_OBS)" CONFIG_DEPS="$CONFIG_DEPS \$(SUBDIR_TUI_DEPS)" CONFIG_SRCS="$CONFIG_SRCS \$(SUBDIR_TUI_SRCS)" ENABLE_CFLAGS="$ENABLE_CFLAGS \$(SUBDIR_TUI_CFLAGS)" else if test x"$enable_tui" = xyes; then AC_MSG_ERROR([no enhanced curses library found; disable TUI]) else AC_MSG_WARN([no enhanced curses library found; disabling TUI]) fi fi fi ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-14 14:20 ` Pedro Alves @ 2024-05-14 17:02 ` Eli Zaretskii 2024-05-14 18:47 ` Pedro Alves 0 siblings, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2024-05-14 17:02 UTC (permalink / raw) To: Pedro Alves; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches > Date: Tue, 14 May 2024 15:20:18 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, ssbssa@yahoo.de, bernd.edlinger@hotmail.de, > gdb-patches@sourceware.org > From: Pedro Alves <pedro@palves.net> > > I just tried cross building a win32 mingw gdb using the posix thread model: > > /home/pedro/gdb/src/configure \ > --disable-ld \ > --disable-binutils \ > --disable-gas \ > --disable-gold \ > --disable-nls \ > --build=x86_64-pc-linux-gnu \ > --host=i686-w64-mingw32 \ > --target=i686-w64-mingw32 \ > --disable-source-highlight \ > --with-static-standard-libraries \ > --with-gmp=/home/pedro/src/gmp/install-win32 \ > --with-mpfr=/home/pedro/src/mpfr/install-win32 \ > --with-expat=yes --with-libexpat-prefix=/home/pedro/src/expat/install-win32/ \ > --enable-threading \ > CC=i686-w64-mingw32-gcc-posix \ > CXX=i686-w64-mingw32-g++-posix \ > CFLAGS="-g3 -O0" \ > CXXFLAGS="-g3 -O0" > > and I got: > > $ wine ./gdb -ex "maintenance show worker-threads" -q --batch > The number of worker threads GDB can use is the default (currently 8). > > I think this binary would work on WinXP, and it supports threads. I suggest that you try. AFAIK, MinGW64 dropped XP support about 2 or more years ago. So a binary built with MinGW64 might not run on XP for that reason. I build GDB using mingw.org's MinGW, which does support XP (and older versions as well), but its pthreads are a different matter -- I had trouble with them and removed it from my system to avoid that. Plus, I'm not sure mingw.org's libstc++ supports <thread> if you build for Posix threading (it definitely does NOT support <thread> for w32 threading). So once again, we should actually try this before we conclude it's possible. > Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread > doesn't work. I think that's a bug. If I explicitly request threading, and then > configure detects std::thread doesn't work, it should error out. Agreed. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-14 17:02 ` Eli Zaretskii @ 2024-05-14 18:47 ` Pedro Alves 2024-05-14 19:19 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Pedro Alves @ 2024-05-14 18:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches On 2024-05-14 18:02, Eli Zaretskii wrote: >> Date: Tue, 14 May 2024 15:20:18 +0100 >> Cc: Eli Zaretskii <eliz@gnu.org>, ssbssa@yahoo.de, bernd.edlinger@hotmail.de, >> gdb-patches@sourceware.org >> From: Pedro Alves <pedro@palves.net> >> >> I just tried cross building a win32 mingw gdb using the posix thread model: >> >> /home/pedro/gdb/src/configure \ >> --disable-ld \ >> --disable-binutils \ >> --disable-gas \ >> --disable-gold \ >> --disable-nls \ >> --build=x86_64-pc-linux-gnu \ >> --host=i686-w64-mingw32 \ >> --target=i686-w64-mingw32 \ >> --disable-source-highlight \ >> --with-static-standard-libraries \ >> --with-gmp=/home/pedro/src/gmp/install-win32 \ >> --with-mpfr=/home/pedro/src/mpfr/install-win32 \ >> --with-expat=yes --with-libexpat-prefix=/home/pedro/src/expat/install-win32/ \ >> --enable-threading \ >> CC=i686-w64-mingw32-gcc-posix \ >> CXX=i686-w64-mingw32-g++-posix \ >> CFLAGS="-g3 -O0" \ >> CXXFLAGS="-g3 -O0" >> >> and I got: >> >> $ wine ./gdb -ex "maintenance show worker-threads" -q --batch >> The number of worker threads GDB can use is the default (currently 8). >> >> I think this binary would work on WinXP, and it supports threads. > > I suggest that you try. AFAIK, MinGW64 dropped XP support about 2 or > more years ago. So a binary built with MinGW64 might not run on XP > for that reason. > > I build GDB using mingw.org's MinGW, which does support XP (and older > versions as well), but its pthreads are a different matter -- I had > trouble with them and removed it from my system to avoid that. Plus, > I'm not sure mingw.org's libstc++ supports <thread> if you build for > Posix threading (it definitely does NOT support <thread> for w32 > threading). > > So once again, we should actually try this before we conclude it's > possible. OK. I will have to leave that for someone who actually has such a system. I do not have one handy. There is also this: https://github.com/meganz/mingw-std-threads Described as: "mingw-std-threads Implementation of standard C++11 threading classes, which are currently still missing on MinGW GCC. Target Windows version This implementation should work with Windows XP (regardless of service pack), or newer. The library automatically detects the version of Windows that is being targeted (at compile time), and selects an implementation that takes advantage of available Windows features. (...)." > >> Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread >> doesn't work. I think that's a bug. If I explicitly request threading, and then >> configure detects std::thread doesn't work, it should error out. > > Agreed. > I sent a patch for that, now: https://inbox.sourceware.org/gdb-patches/20240514184341.1399428-1-pedro@palves.net/T/#u ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-14 18:47 ` Pedro Alves @ 2024-05-14 19:19 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2024-05-14 19:19 UTC (permalink / raw) To: Pedro Alves; +Cc: tromey, ssbssa, bernd.edlinger, gdb-patches > Date: Tue, 14 May 2024 19:47:48 +0100 > Cc: tromey@adacore.com, ssbssa@yahoo.de, bernd.edlinger@hotmail.de, > gdb-patches@sourceware.org > From: Pedro Alves <pedro@palves.net> > > > I build GDB using mingw.org's MinGW, which does support XP (and older > > versions as well), but its pthreads are a different matter -- I had > > trouble with them and removed it from my system to avoid that. Plus, > > I'm not sure mingw.org's libstc++ supports <thread> if you build for > > Posix threading (it definitely does NOT support <thread> for w32 > > threading). > > > > So once again, we should actually try this before we conclude it's > > possible. > > OK. I will have to leave that for someone who actually has such a system. > I do not have one handy. > > There is also this: > > https://github.com/meganz/mingw-std-threads > > Described as: > > "mingw-std-threads > Implementation of standard C++11 threading classes, which are currently still missing on MinGW GCC. > > Target Windows version > This implementation should work with Windows XP (regardless of service pack), or newer. The library automatically > detects the version of Windows that is being targeted (at compile time), and selects an implementation that > takes advantage of available Windows features. (...)." I know. But AFAIR integrating it with libstdc++ is not a simple job, and no one has done that yet. > >> Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread > >> doesn't work. I think that's a bug. If I explicitly request threading, and then > >> configure detects std::thread doesn't work, it should error out. > > > > Agreed. > > > > I sent a patch for that, now: > > https://inbox.sourceware.org/gdb-patches/20240514184341.1399428-1-pedro@palves.net/T/#u Thanks. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 17:24 ` Tom Tromey ` (2 preceding siblings ...) 2024-05-10 19:03 ` Pedro Alves @ 2024-05-11 10:55 ` Hannes Domani 2024-05-13 13:45 ` Tom Tromey 3 siblings, 1 reply; 25+ messages in thread From: Hannes Domani @ 2024-05-11 10:55 UTC (permalink / raw) To: Tom Tromey; +Cc: Bernd Edlinger, gdb-patches Am Freitag, 10. Mai 2024 um 19:24:21 MESZ hat Tom Tromey <tromey@adacore.com> Folgendes geschrieben: > >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: > > Hannes> If you don't need XP support, can't you just define _WIN32_WINNT > Hannes> in CPPFLAGS? > > Yeah, it seems possible. Maybe the problem is that unless you remember > this (it seems pretty obscure), a mingw build with a newer version of > GCC is going to fail due to libstdc++ wanting an older version that > gdb's default. I don't understand, why would the mingw build fail in this case? Hannes ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-11 10:55 ` Hannes Domani @ 2024-05-13 13:45 ` Tom Tromey 0 siblings, 0 replies; 25+ messages in thread From: Tom Tromey @ 2024-05-13 13:45 UTC (permalink / raw) To: Hannes Domani; +Cc: Tom Tromey, Bernd Edlinger, gdb-patches >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes: Hannes> If you don't need XP support, can't you just define _WIN32_WINNT Hannes> in CPPFLAGS? >> Yeah, it seems possible. Maybe the problem is that unless you remember >> this (it seems pretty obscure), a mingw build with a newer version of >> GCC is going to fail due to libstdc++ wanting an older version that >> gdb's default. Hannes> I don't understand, why would the mingw build fail in this case? I think the problem that was recently fixed was just this kind of failure. The problem here is that gdb sets _WIN32_WINNT to a value that is too low -- libstdc++ assumes a higher value. So, before the configure patch (commit 45e83f86) landed, including <mutex> would cause problems, because that header assumes _WIN32_WINNT >= 0x0600. Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-06 20:18 ` Tom Tromey 2024-05-07 10:59 ` Hannes Domani @ 2024-05-10 17:39 ` Eli Zaretskii 2024-05-13 13:48 ` Tom Tromey 1 sibling, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2024-05-10 17:39 UTC (permalink / raw) To: Tom Tromey; +Cc: bernd.edlinger, gdb-patches > From: Tom Tromey <tromey@adacore.com> > Cc: Tom Tromey <tromey@adacore.com>, "gdb-patches@sourceware.org" > <gdb-patches@sourceware.org> > Date: Mon, 06 May 2024 14:18:16 -0600 > > >>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes: > > >> I wonder if we could change _WIN32_WINNT when threading is enabled, so > >> the new gcc support could be used. > > Bernd> frankly I don't understand at all why the _WIN32_WINNT is set to this > Bernd> specific value, and maybe that was a good idea when windows XP was the > Bernd> latest version. My feeling would be to remove that define all together. > > The addition itself seems to be commit 353ea2d1, which has some > explanation. I gather the idea is that, this way, a gdb built on > Windows will work all the way back to NT. > > I tried changing the value but Eli objected: > > https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html > > Internally at AdaCore we still have this part of the change installed, > precisely to pick up the mingw threading support from gcc; plus we have > no need for Windows XP. > > >From https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle, I > gather that XP is still in reasonably wide use. I'm not sure how many > developers use it, though, or even if gdb actually does run there, not > having access to such a machine myself. > > I'm sympathetic to changing this somehow but I don't know how to make > progress on it. Once again, that change was not supposed to lower the value of _WIN32_WINNT, only to raise it if by default it is lower than 0x0501. If that's not what happens nowadays, I think we need to understand why, and fix it so it doesn't lower the value. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 17:39 ` Eli Zaretskii @ 2024-05-13 13:48 ` Tom Tromey 0 siblings, 0 replies; 25+ messages in thread From: Tom Tromey @ 2024-05-13 13:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Tom Tromey, bernd.edlinger, gdb-patches >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes: Eli> Once again, that change was not supposed to lower the value of Eli> _WIN32_WINNT, only to raise it if by default it is lower than 0x0501. Eli> If that's not what happens nowadays, I think we need to understand Eli> why, and fix it so it doesn't lower the value. The code is: #if defined (__MINGW32__) || defined (__CYGWIN__) # ifdef _WIN32_WINNT # if _WIN32_WINNT < 0x0602 # undef _WIN32_WINNT # define _WIN32_WINNT 0x0602 # endif # else # define _WIN32_WINNT 0x0602 # endif #endif /* __MINGW32__ || __CYGWIN__ */ Probably at this point _WIN32_WINNT is not set and so it takes the else branch. I didn't really check this though. However, I thought the point of this code was to set up a compilation environment that was "XP-like" -- that is, require all later-than-XP APIs to be discovered dynamically. Tom ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-06 17:09 ` Bernd Edlinger 2024-05-06 20:18 ` Tom Tromey @ 2024-05-10 17:37 ` Eli Zaretskii 2024-05-10 19:36 ` Bernd Edlinger 1 sibling, 1 reply; 25+ messages in thread From: Eli Zaretskii @ 2024-05-10 17:37 UTC (permalink / raw) To: Bernd Edlinger; +Cc: tom, gdb-patches > Date: Mon, 6 May 2024 19:09:37 +0200 > Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> > From: Bernd Edlinger <bernd.edlinger@hotmail.de> > > On 5/6/24 16:57, Tom Tromey wrote: > >>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes: > > > > Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue > > Bernd> whether or not the --disable-threading option is used. > > Bernd> The problem happens because _WIN32_WINNT is defined to 0x501 > > Bernd> before #include <mutex> which makes the compilation abort > > Bernd> due to missing support for __gthread_cond_t in std_mutex.h, > > Bernd> which is conditional on _WIN32_WINNT >= 0x600. > > > > Bernd> Fix the case when --disable-threading is used, by only > > Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD > > Bernd> is defined. > > > > Bernd> Additionally make the configure script try to #include <mutex> > > Bernd> to automatically select --disable-threading when the header file > > Bernd> is not able to compile. > > > > This looks reasonable to me. Thank you. > > Approved-By: Tom Tromey <tom@tromey.com> > > > > Okay, pushed. > > > I wonder if we could change _WIN32_WINNT when threading is enabled, so > > the new gcc support could be used. > > > > frankly I don't understand at all why the _WIN32_WINNT is set to this > specific value, and maybe that was a good idea when windows XP was the > latest version. My feeling would be to remove that define all together. > > The code looks like its intention is to raise the _WIN32_WINNT from > 4.x to 5.01, but instead it lowers the _WIN32_WINNT version > from 10.0 to 5.01 at least with my toolchain, where this define is not > a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>, > but only if it is not fixed to something else. That was not the intent, and if that setting lowers the value of _WIN32_WINNT, we should IMO investigate why and fix that. > However I am not an expert in this area, and I have only tried this with > my self-built cross-toolchain. What I can tell, is that although I have > no working <pthread.h> in my sysroot, the std::thread implementation seems > to work, as long as _WIN32_WINNT is set to something >= 0x0600. If your MinGW headers have _WIN32_WINNT set to a value higher than 0x0501, that setting should have left it alone. Please try to figure out why that doesn't happen in your case, perhaps MinGW64 have changed their defaults or something. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 17:37 ` Eli Zaretskii @ 2024-05-10 19:36 ` Bernd Edlinger 2024-05-11 6:18 ` Eli Zaretskii 0 siblings, 1 reply; 25+ messages in thread From: Bernd Edlinger @ 2024-05-10 19:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: tom, gdb-patches Hi Eli, On 5/10/24 19:37, Eli Zaretskii wrote: >> Date: Mon, 6 May 2024 19:09:37 +0200 >> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> >> From: Bernd Edlinger <bernd.edlinger@hotmail.de> >> >> On 5/6/24 16:57, Tom Tromey wrote: >>> I wonder if we could change _WIN32_WINNT when threading is enabled, so >>> the new gcc support could be used. >>> >> >> frankly I don't understand at all why the _WIN32_WINNT is set to this >> specific value, and maybe that was a good idea when windows XP was the >> latest version. My feeling would be to remove that define all together. >> >> The code looks like its intention is to raise the _WIN32_WINNT from >> 4.x to 5.01, but instead it lowers the _WIN32_WINNT version >> from 10.0 to 5.01 at least with my toolchain, where this define is not >> a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>, >> but only if it is not fixed to something else. > > That was not the intent, and if that setting lowers the value of > _WIN32_WINNT, we should IMO investigate why and fix that. > Hmm, what happens here is that _WIN32_WINNT is not a pre-defined symbol, but __MINGW32__ is pre-defined. So _WIN32_WINNT is not defined unless <windows.h> is included first, but when "gdbsupport/common-defs.h" is included, the _WIN32_WINNT is not yet defined, and therefore it is set to 0x0501, now, later when <windows.h> is included, it includes <_mingw.h>, but since the _WIN32_WINNT is already defined to 0x0501 that is kept this way. And now, the <mutex> header file wont compile, because the gthread.h is missing support for something similar to a pthread condition variable. I tried to include <windows.h> before overriding the _WIN32_WINNT define, but that caused issues with something like <winsock2.h> if I remember correctly. I did not try to include <_mingw.h> because I expected that to cause even more unexpected issues, e.g. with cygwin. >> However I am not an expert in this area, and I have only tried this with >> my self-built cross-toolchain. What I can tell, is that although I have >> no working <pthread.h> in my sysroot, the std::thread implementation seems >> to work, as long as _WIN32_WINNT is set to something >= 0x0600. > > If your MinGW headers have _WIN32_WINNT set to a value higher than > 0x0501, that setting should have left it alone. Please try to figure > out why that doesn't happen in your case, perhaps MinGW64 have changed > their defaults or something. BTW: I tried the resulting executable with a Windows 10 VM, and it worked, but: $ x86_64-pc-mingw32-objdump -x gdb.exe | grep DLL vma: Hint Time Forward DLL First DLL Name: bcrypt.dll DLL Name: KERNEL32.dll DLL Name: api-ms-win-crt-conio-l1-1-0.dll DLL Name: api-ms-win-crt-convert-l1-1-0.dll DLL Name: api-ms-win-crt-environment-l1-1-0.dll DLL Name: api-ms-win-crt-filesystem-l1-1-0.dll DLL Name: api-ms-win-crt-heap-l1-1-0.dll DLL Name: api-ms-win-crt-locale-l1-1-0.dll DLL Name: api-ms-win-crt-math-l1-1-0.dll DLL Name: api-ms-win-crt-private-l1-1-0.dll DLL Name: api-ms-win-crt-runtime-l1-1-0.dll DLL Name: api-ms-win-crt-stdio-l1-1-0.dll DLL Name: api-ms-win-crt-string-l1-1-0.dll DLL Name: api-ms-win-crt-time-l1-1-0.dll DLL Name: api-ms-win-crt-utility-l1-1-0.dll DLL Name: USER32.dll DLL Name: WS2_32.dll So I am not an expert in this area, and I have not tried to run this on a native XP machine, but somehow I wonder if defining _WIN32_WINNT to 0x501 does still do the trick that makes it execute on Windows XP ? What do you think? Thanks Bernd. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Fix build issues with mingw toolchain 2024-05-10 19:36 ` Bernd Edlinger @ 2024-05-11 6:18 ` Eli Zaretskii 0 siblings, 0 replies; 25+ messages in thread From: Eli Zaretskii @ 2024-05-11 6:18 UTC (permalink / raw) To: Bernd Edlinger; +Cc: tom, gdb-patches > Date: Fri, 10 May 2024 21:36:42 +0200 > Cc: tom@tromey.com, gdb-patches@sourceware.org > From: Bernd Edlinger <bernd.edlinger@hotmail.de> > > >> frankly I don't understand at all why the _WIN32_WINNT is set to this > >> specific value, and maybe that was a good idea when windows XP was the > >> latest version. My feeling would be to remove that define all together. > >> > >> The code looks like its intention is to raise the _WIN32_WINNT from > >> 4.x to 5.01, but instead it lowers the _WIN32_WINNT version > >> from 10.0 to 5.01 at least with my toolchain, where this define is not > >> a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>, > >> but only if it is not fixed to something else. > > > > That was not the intent, and if that setting lowers the value of > > _WIN32_WINNT, we should IMO investigate why and fix that. > > Hmm, what happens here is that _WIN32_WINNT is not a pre-defined symbol, > but __MINGW32__ is pre-defined. So _WIN32_WINNT is not defined unless > <windows.h> is included first, but when "gdbsupport/common-defs.h" > is included, the _WIN32_WINNT is not yet defined, and therefore it is > set to 0x0501, now, later when <windows.h> is included, it includes > <_mingw.h>, but since the _WIN32_WINNT is already defined to 0x0501 > that is kept this way. And now, the <mutex> header file wont compile, > because the gthread.h is missing support for something similar to a > pthread condition variable. Thanks, I think I understand what happens, see below. > I tried to include <windows.h> before overriding the _WIN32_WINNT define, > but that caused issues with something like <winsock2.h> if I remember > correctly. I did not try to include <_mingw.h> because I expected > that to cause even more unexpected issues, e.g. with cygwin. No, _mingw.h is not supposed to define the default value of _WIN32_WINNT. It used to be w32api.h, and in mingw.org's MinGW that still happens. But MinGW64 deviated from that, so we need to adapt. According to the Microsoft documentation, the default value of _WIN32_WINNT is defined in sdkddkver.h, see https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 So what we need is to have #include <sdkddkver.h> before the first test of _WIN32_WINNT, and then it should work in both flavors on MinGW. I verified that this header defines _WIN32_WINNT in both flavors of MinGW. Alternatively, we could unconditionally define _WIN32_WINNT to 0x0600, if that is needed for threading support. AFAIU, it should not interfere with what common-defs.h is trying to do now, since the problem that fragment tries to solve is to make sure _WIN32_WINNT is not defined to anything _lower_ than 0x0501. I think this alternative is cleaner, since sdkddkver.h is included from windows.h and defines additional version-related constants based on _WIN32_WINNT (which other Windows headers perhaps need). If you decide to use this latter alternative, please add there a comment saying that we still support XP, but 0x0600 is required for threading when it is supported on Windows. > BTW: I tried the resulting executable with a Windows 10 VM, and it worked, > but: > > $ x86_64-pc-mingw32-objdump -x gdb.exe | grep DLL > vma: Hint Time Forward DLL First > DLL Name: bcrypt.dll > DLL Name: KERNEL32.dll > DLL Name: api-ms-win-crt-conio-l1-1-0.dll > DLL Name: api-ms-win-crt-convert-l1-1-0.dll > DLL Name: api-ms-win-crt-environment-l1-1-0.dll > DLL Name: api-ms-win-crt-filesystem-l1-1-0.dll > DLL Name: api-ms-win-crt-heap-l1-1-0.dll > DLL Name: api-ms-win-crt-locale-l1-1-0.dll > DLL Name: api-ms-win-crt-math-l1-1-0.dll > DLL Name: api-ms-win-crt-private-l1-1-0.dll > DLL Name: api-ms-win-crt-runtime-l1-1-0.dll > DLL Name: api-ms-win-crt-stdio-l1-1-0.dll > DLL Name: api-ms-win-crt-string-l1-1-0.dll > DLL Name: api-ms-win-crt-time-l1-1-0.dll > DLL Name: api-ms-win-crt-utility-l1-1-0.dll > DLL Name: USER32.dll > DLL Name: WS2_32.dll > > So I am not an expert in this area, and I have not tried to run this on a > native XP machine, but somehow I wonder if defining _WIN32_WINNT to 0x501 > does still do the trick that makes it execute on Windows XP ? It does, I actually run GDB on Windows XP. GDB will run on XP as long as you don't link it against the new UCRT runtime, but against the original MSVCRT runtime. The above dependency DLLs seem to indicate that your link is against UCRT, I think. MinGW64 currently supports both MSVCRT and UCRT builds, and mingw.org's MinGW supports only MSVCRT. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2024-05-15 2:20 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-05-06 5:58 [PATCH] Fix build issues with mingw toolchain Bernd Edlinger 2024-05-06 14:57 ` Tom Tromey 2024-05-06 17:09 ` Bernd Edlinger 2024-05-06 20:18 ` Tom Tromey 2024-05-07 10:59 ` Hannes Domani 2024-05-10 17:24 ` Tom Tromey 2024-05-10 17:32 ` Eli Zaretskii 2024-05-10 17:41 ` Eli Zaretskii 2024-05-10 19:03 ` Pedro Alves 2024-05-11 6:20 ` Eli Zaretskii 2024-05-13 14:21 ` Pedro Alves 2024-05-13 15:36 ` Eli Zaretskii 2024-05-13 17:12 ` Pedro Alves 2024-05-13 18:45 ` Tom Tromey 2024-05-14 14:20 ` Pedro Alves 2024-05-14 17:02 ` Eli Zaretskii 2024-05-14 18:47 ` Pedro Alves 2024-05-14 19:19 ` Eli Zaretskii 2024-05-11 10:55 ` Hannes Domani 2024-05-13 13:45 ` Tom Tromey 2024-05-10 17:39 ` Eli Zaretskii 2024-05-13 13:48 ` Tom Tromey 2024-05-10 17:37 ` Eli Zaretskii 2024-05-10 19:36 ` Bernd Edlinger 2024-05-11 6:18 ` Eli Zaretskii
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).