[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #30 from Jonathan Wakely --- Created attachment 54255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54255=edit Disable C++11 mutex etc. when not supported by win32 threads This patch would solve the problem for and , but would not do anything about the fact that this would still fail: #define _WIN32_WINNT 0x0502 #include If you can't even include then the library is unusable, so we're not going to attempt to support that. As I said in the last comment, it will work if libstdc++ is configured with the ancient value of _WIN32_WINNT, but selecting those ancient versions after installation by defining it in your own code won't work. I'll document this in the manual.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #29 from Jonathan Wakely --- I think if you want to build for ancient versions < 0x0600 then you should build a custom toolchain for that. Build the whole compiler with --enable-cxx-flags="-O2 -g -D_WIN32_WINNT=0x0500" and that way libstdc++'s configure will correctly detect at build time that you are from prehistoric times. It will correctly disable uses of C99 stdlib.h and C++11 mutexes and threads etc. Building a compiler for modern Windows versions and expecting it to also compile for ancient versions is not going to work. Treat the ancient versions as a cross-compilation target and use a custom toolchain instead. So I'm closing this again.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #28 from Jonathan Wakely --- (In reply to cqwrteur from comment #2) > Please stop! Windows 95 support is extremely important Looks like you can't even include if you set _WIN32_WINNT < 0x0600 so this has NEVER worked, and I don't see why we should waste our time supporting it.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|ASSIGNED Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #27 from Jonathan Wakely --- Gah, this doesn't work (and not only because it should be not ). We include os_defines.h before the line create by configure: #include ... #define _GLIBCXX_HAS_GTHREADS 1 I have a fix, but it will have to wait for higher priority things to be done first.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #26 from Eric Botcazou --- > For --enable-threads=posix the value of _WIN32_WINNT doesn't matter, so we > don't want to disable _GLIBCXX_HAS_GTHREADS in that case. That's why we need > to include , to find out if it's actually affected by _WIN32_WINNT. OK, indeed I totally overlooked the other threading models... > But IMHO we don't want to include unconditionally in every single > libstdc++ header (because they all include which includes > this os_defines.h header). So only do it if _WIN32_WINNT has been set to > some ancient value, because otherwise the problem doesn't exist. Fair enough, although it only drags stdlib.h and sys/timeb.h if you define __GTHREAD_HIDE_WIN32API like libstdc++ does.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #25 from Jonathan Wakely --- For --enable-threads=posix the value of _WIN32_WINNT doesn't matter, so we don't want to disable _GLIBCXX_HAS_GTHREADS in that case. That's why we need to include , to find out if it's actually affected by _WIN32_WINNT. But IMHO we don't want to include unconditionally in every single libstdc++ header (because they all include which includes this os_defines.h header). So only do it if _WIN32_WINNT has been set to some ancient value, because otherwise the problem doesn't exist.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #24 from Eric Botcazou --- > Maybe we want something like this: > > diff --git a/libstdc++-v3/config/os/mingw32-w64/os_defines.h > b/libstdc++-v3/config/os/mingw32-w64/os_defines.h > index ee02ff82e86..68ac100acc8 100644 > --- a/libstdc++-v3/config/os/mingw32-w64/os_defines.h > +++ b/libstdc++-v3/config/os/mingw32-w64/os_defines.h > @@ -96,4 +96,13 @@ > // See libstdc++/94268 > #define _GLIBCXX_BUFSIZ 4096 > > +#if _WIN32_WINNT < 0x0600 > +// For the win32 thread model, setting _WIN32_WINNT to an old version might > +// invalidate the value of _GLIBCXX_HAS_GTHREADS decided during configure. > +# include > +# ifndef __GTHREADS_CXX0X > +# undef _GLIBCXX_HAS_GTHREADS > +# endif > +#endif > + > #endif IMO either you do not test _WIN32_WINNT but just __GTHREADS_CXX0X, or you just test _WIN32_WINNT and avoiding including & testing __GTHREADS_CXX0X.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Jonathan Wakely changed: What|Removed |Added Resolution|MOVED |--- Status|RESOLVED|REOPENED --- Comment #23 from Jonathan Wakely --- The problem now is that using a different value of _WIN32_WINNT invalidates what was used during libstdc++'s configure, making _GLIBCXX_HAS_GTHREADS incorrect. Maybe we want something like this: diff --git a/libstdc++-v3/config/os/mingw32-w64/os_defines.h b/libstdc++-v3/config/os/mingw32-w64/os_defines.h index ee02ff82e86..68ac100acc8 100644 --- a/libstdc++-v3/config/os/mingw32-w64/os_defines.h +++ b/libstdc++-v3/config/os/mingw32-w64/os_defines.h @@ -96,4 +96,13 @@ // See libstdc++/94268 #define _GLIBCXX_BUFSIZ 4096 +#if _WIN32_WINNT < 0x0600 +// For the win32 thread model, setting _WIN32_WINNT to an old version might +// invalidate the value of _GLIBCXX_HAS_GTHREADS decided during configure. +# include +# ifndef __GTHREADS_CXX0X +# undef _GLIBCXX_HAS_GTHREADS +# endif +#endif + #endif
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Resolution|--- |MOVED Status|WAITING |RESOLVED
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|MOVED |---
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #22 from cqwrteur ---
(In reply to cqwrteur from comment #19)
> (In reply to cqwrteur from comment #18)
> > (In reply to cqwrteur from comment #17)
> > > (In reply to Eric Botcazou from comment #16)
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #define __GTHREAD_HAS_COND 1
> > > > > #define __GTHREADS_CXX0X 1
> > > > > #endif
> > > > >
> > > > > I suggest remove this macro in the header due to potential breakage
> > > > >
> > > > > #if _WIN32_WINNT >= 0x0600
> > > > > #endif
> > > >
> > > > That's nonsensical.
> > >
> > > The problem is that libstdc++ would instantly break if someone randomly
> > > defines _WIN32_WINNT (like gdb does).
> >
> > The solution would probably be for libstdc++ to guard against
> > __GHTREAD_HAS_COND instead
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=29966
not working
d-pool.cc:21:
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:164:5:
error: '__gthread_cond_t' does not name a type; did you mean
'__gthread_once_t'?
164 | __gthread_cond_t* native_handle() noexcept { return &_M_cond; }
| ^~~~
| __gthread_once_t
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:208:5:
error: '__gthread_cond_t' does not name a type; did you mean
'__gthread_once_t'?
208 | __gthread_cond_t _M_cond;
| ^~~~
| __gthread_once_t
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:
In constructor 'std::__condvar::__condvar()':
/home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/include/c++/13.0.0/bits/std_mutex.h:151:37:
error: '_M_cond' was not declared in this scope
151 | __GTHREAD_COND_INIT_FUNCTION(&_M_cond);
| ^~~
CC ldcref.o
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Jonathan Wakely changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29966 Status|WAITING |RESOLVED Resolution|--- |MOVED --- Comment #21 from Jonathan Wakely --- (In reply to cqwrteur from comment #18) > The solution would probably be for libstdc++ to guard against > __GHTREAD_HAS_COND instead No it wouldn't, you don't know what you're talking about. That's defined under exactly the same condition as the __GTHREADS_CXX0X macro that libstdc++ uses, so it would make no difference at all. This is a GDB bug which has a configure check for std::thread which doesn't work with GCC 13. See the linked GDB bug report.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #20 from cqwrteur --- (In reply to cqwrteur from comment #19) > (In reply to cqwrteur from comment #18) > > (In reply to cqwrteur from comment #17) > > > (In reply to Eric Botcazou from comment #16) > > > > > #if _WIN32_WINNT >= 0x0600 > > > > > #define __GTHREAD_HAS_COND 1 > > > > > #define __GTHREADS_CXX0X 1 > > > > > #endif > > > > > > > > > > I suggest remove this macro in the header due to potential breakage > > > > > > > > > > #if _WIN32_WINNT >= 0x0600 > > > > > #endif > > > > > > > > That's nonsensical. > > > > > > The problem is that libstdc++ would instantly break if someone randomly > > > defines _WIN32_WINNT (like gdb does). > > > > The solution would probably be for libstdc++ to guard against > > __GHTREAD_HAS_COND instead > > https://sourceware.org/bugzilla/show_bug.cgi?id=29966 D:\msys64\home\unlvs\projects\fast_io\examples\0001.helloworld>g++ -o helloworld helloworld.cc -Ofast -std=c++23 -s -flto -march=native -I../../include d:/x86_64-windows-gnu/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe: helloworld.exe:.rdata_r: section below image base Do not know why.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #19 from cqwrteur --- (In reply to cqwrteur from comment #18) > (In reply to cqwrteur from comment #17) > > (In reply to Eric Botcazou from comment #16) > > > > #if _WIN32_WINNT >= 0x0600 > > > > #define __GTHREAD_HAS_COND 1 > > > > #define __GTHREADS_CXX0X 1 > > > > #endif > > > > > > > > I suggest remove this macro in the header due to potential breakage > > > > > > > > #if _WIN32_WINNT >= 0x0600 > > > > #endif > > > > > > That's nonsensical. > > > > The problem is that libstdc++ would instantly break if someone randomly > > defines _WIN32_WINNT (like gdb does). > > The solution would probably be for libstdc++ to guard against > __GHTREAD_HAS_COND instead https://sourceware.org/bugzilla/show_bug.cgi?id=29966
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #18 from cqwrteur --- (In reply to cqwrteur from comment #17) > (In reply to Eric Botcazou from comment #16) > > > #if _WIN32_WINNT >= 0x0600 > > > #define __GTHREAD_HAS_COND 1 > > > #define __GTHREADS_CXX0X 1 > > > #endif > > > > > > I suggest remove this macro in the header due to potential breakage > > > > > > #if _WIN32_WINNT >= 0x0600 > > > #endif > > > > That's nonsensical. > > The problem is that libstdc++ would instantly break if someone randomly > defines _WIN32_WINNT (like gdb does). The solution would probably be for libstdc++ to guard against __GHTREAD_HAS_COND instead
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|WONTFIX |--- --- Comment #17 from cqwrteur --- (In reply to Eric Botcazou from comment #16) > > #if _WIN32_WINNT >= 0x0600 > > #define __GTHREAD_HAS_COND 1 > > #define __GTHREADS_CXX0X 1 > > #endif > > > > I suggest remove this macro in the header due to potential breakage > > > > #if _WIN32_WINNT >= 0x0600 > > #endif > > That's nonsensical. The problem is that libstdc++ would instantly break if someone randomly defines _WIN32_WINNT (like gdb does).
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Eric Botcazou changed: What|Removed |Added Resolution|--- |WONTFIX Status|REOPENED|RESOLVED --- Comment #16 from Eric Botcazou --- > #if _WIN32_WINNT >= 0x0600 > #define __GTHREAD_HAS_COND 1 > #define __GTHREADS_CXX0X 1 > #endif > > I suggest remove this macro in the header due to potential breakage > > #if _WIN32_WINNT >= 0x0600 > #endif That's nonsensical.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #15 from cqwrteur --- (In reply to Jonathan Wakely from comment #14) > And it isn't specific to Canadian cross compilation either. It happens for > any build with the latest mingw-w64 headers, both native and cross. And that > has nothing to do with std::mutex, which is the subject of this bug report. #if _WIN32_WINNT >= 0x0600 #define __GTHREAD_HAS_COND 1 #define __GTHREADS_CXX0X 1 #endif I suggest remove this macro in the header due to potential breakage #if _WIN32_WINNT >= 0x0600 #endif
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #14 from Jonathan Wakely --- And it isn't specific to Canadian cross compilation either. It happens for any build with the latest mingw-w64 headers, both native and cross. And that has nothing to do with std::mutex, which is the subject of this bug report.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #13 from Jonathan Wakely --- That's PR 108300 and has nothing to do with "macro pollution of __FILE__".
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #12 from cqwrteur --- (In reply to cqwrteur from comment #11) > The problem is that it breaks gcc build too. GCC won't build any more due to > macro pollution of __FILE__ x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc/./isl/include -I/home/cqwrteur/toolchains_build/gcc/isl/include -o cp/cvt.o -MT cp/cvt.o -MMD -MP -MF cp/.deps/cvt.TPo /home/cqwrteur/toolchains_build/gcc/gcc/cp/cvt.cc make[2]: *** [Makefile:1148: diagnostic-color.o] Error 1 make[2]: *** Waiting for unfinished jobs /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected identifier before string constant 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__) | ^~~~ /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or '...' before string constant /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected identifier before string constant 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__) | ^~~~ /home/cqwrteur/toolchains_build/gcc/gcc/system.h:791:30: error: expected ',' or '...' before string constant It looks like macro pollution also causes the Canadian compilation for GCC to fail. __FILE__ macro fails.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 cqwrteur changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX |--- --- Comment #11 from cqwrteur --- The problem is that it breaks gcc build too. GCC won't build any more due to macro pollution of __FILE__
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WONTFIX Status|WAITING |RESOLVED --- Comment #10 from Jonathan Wakely --- (In reply to cqwrteur from comment #3) > libstdc++ completely ignores __GTHREAD_HAS_COND macro which cause build > failure for gdb If GDB requires then it requires working C++11 thread support, which has never worked for the win32 thread model with -D_WIN32_WINNT=0x0500. With GCC 12, gthr-win32.h simply doesn't support std::mutex, period. With GCC 13 it supports it for modern Windows versions: /* Condition variables are supported on Vista and Server 2008 or later. */ #if _WIN32_WINNT >= 0x0600 #define __GTHREAD_HAS_COND 1 #define __GTHREADS_CXX0X 1 #endif For older Windows versions, the win32 thread model doesn't support std::mutex etc. There is no C++11 threading support for Win95 using --enable-threads=win32. If you don't like it, either don't compile for Win95 or use a different thread model. Ranting and raving that unsupported things don't work is a waste of time.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #9 from Jonathan Wakely --- (In reply to cqwrteur from comment #2) > Please stop! Windows 95 support is extremely important No it isn't. (In reply to cqwrteur from comment #4) > The entire win32 thread model is a mess. It does not support the thread > model well enough while causing enormous pain. If users need threading, they > can use posix and mcf. Why win32?? If you don't want to use the win32 model, you don't have to use it.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 --- Comment #8 from Jonathan Wakely --- (In reply to Eric Botcazou from comment #7) > Btw the code goes to great length to avoid including from the > libstdc++ header files (see __GTHREAD_HIDE_WIN32API) so it is definitely not. This reporter has a habit of glancing at the code, making assumptions, then insulting us for things we didn't do.
[Bug libstdc++/108225] canadian compilation of gdb error for libstdc++'s std_mutex.h on x86_64-w64-mingw32 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-01-04 --- Comment #7 from Eric Botcazou --- What GCC sources do you use? What does 'gcc -v' output? The error you get is the usual error when trying to include for a threading model not supporting C++11 mutexes, which is the case for the Win32 threading model. Btw the code goes to great length to avoid including from the libstdc++ header files (see __GTHREAD_HIDE_WIN32API) so it is definitely not.
