Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Miguel Gimenez on June 01, 2020, 12:17:42 pm
-
The mutex added to DirectoryParamsPanel.cpp in a recent commit breaks compilation (mutex is not part of namespace std) in all MinGW versions except the posix-seh one, due to problems with win32 threads.
Of course the toolchain can be changed, but this forces recompiling (at least) wxWidgets and boost. Also, posix-seh version only exists for 64-bit MSW, so 32-bit users are stuck.
Can std::mutex be replaced with wxMutex?
EDIT: patch added
-
Do you have link documenting these thing? I doubt this is the case, but I suppose everything could be expected by MinGW people.
I guess it is time to switch to llvm/clang+libc++ on windows...
-
Do you have link documenting these thing?
I have some links with sparse information, for example this is about an older version but things have not changed.
https://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type (https://stackoverflow.com/questions/14191566/c-mutex-in-namespace-std-does-not-name-a-type)
I tested MinGW-W64 GCC-8.1.0 x86_64-win32-sjlj and MinGW-7.2.0, both failed. GCC-8.1.0 x86_64-posix-seh did compile succesfully.
Vadim Zeitlim from wxWidgets' team tested today MinGW-W64 GCC-9.3-win32 and compilation failed. His answer has a link to an ongoing discussion in MinGW-W64 mailing list.
https://github.com/wxWidgets/wxWidgets/commit/66c8437952f970a1a896d67c0ba6838591cf03b6#commitcomment-39582459 (https://github.com/wxWidgets/wxWidgets/commit/66c8437952f970a1a896d67c0ba6838591cf03b6#commitcomment-39582459)
-
MinGW should be dumped...
https://gcc-mcf.lhmouse.com/ is something done by a mingw-w64 dev and he is not able to make it mainstream for 4 years.
-
I am also hitting this problem ;(
-
Using llvm/clang+libc++ on windows https://github.com/mstorsjo/llvm-mingw (https://github.com/mstorsjo/llvm-mingw) I was able to compile wxWidgets but never Boost.
If you manage to compile Boost, please share your experience.
TIA.
-
Chrome and Firefox are build with clang now, so if they could be built, everything could be built.
@bluehazzard: I think you've tested this and haven't reported any problems. :(
-
Fixed in trunk. It is funny why the no-pch build succeeds without the inclusion of wx/thread.h :(
-
@bluehazzard: I think you've tested this and haven't reported any problems.
I have tested it on my other system, so probably there i use the right compiler... sry about that....
-
Fixed in trunk. It is funny why the no-pch build succeeds without the inclusion of wx/thread.h :(
The wonders of transitive includes. Still that shouldn't stop you to produce self-sufficient headers by including everything you use (or use some documented service-headers that pull in common includes), otherwise you will get trouble later when transitivity changes ;)
-
... Still that shouldn't stop you to produce self-sufficient headers by including everything you use...
Too late...