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...
QuoteDo 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 :(
Quote@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....
Quote from: oBFusCATed on June 03, 2020, 12:06:08 AM
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 ;)
Quote from: sodev on June 03, 2020, 04:15:44 PM
... Still that shouldn't stop you to produce self-sufficient headers by including everything you use...
Too late...