Use of std::mutex in ThreadSearch breaks compilation on (most) MinGW

[Miguel Gimenez]

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

[oBFusCATed]

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...

[Miguel Gimenez]

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

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

[oBFusCATed]

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.

[BlueHazzard]

I am also hitting this problem ;(

[tomay3000]

Using llvm/clang+libc++ on windows 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.

[oBFusCATed]

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.

[oBFusCATed]

Fixed in trunk. It is funny why the no-pch build succeeds without the inclusion of wx/thread.h

[BlueHazzard]

@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....

[sodev]

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

[oBFusCATed]

... Still that shouldn't stop you to produce self-sufficient headers by including everything you use...

Too late...