Help to compile ThirdParty/loguru under Windows 10 with gnu c++ 9.2


I am trying to compile VTK under Window 10 with gnu 9.2 for Windows from here:

The cmake command is:
cmake -DCMAKE_MAKE_PROGRAM=make -DCMAKE_CXX_COMPILER=g++ -G “Unix Makefiles” …

I have compiled all other Third Party package successfully, but this loguru gives some errors like:

error: ‘recursive_mutex’ in namespace ‘std’ does not name a type

I searched the net, maybe it is about multithreading like this:

As said in that post, maybe I should use the GCC-related tools suffixed -posix as opposed to -win32, how do I do it?

BTW: could I switch off this package and try compile the rest first?

Thanks for help.



Hi, cean,

So you’re under Windows and want to generate Unix makefiles, right? Then I guess you’re using a gcc from some Unix environment/toolset in Windows like MSYS, MSYS2, MinGW, MinGW64 or Cygwin. Which one are you using?



I’ve just realized you’re using a compiler I’ve never heard of. Interesting. Yes, mutexes (short of mutual exclusion) are structures to avoid race conditions in mutithreading programs (such as trying to write to the same file from different threads at the same time).

After reading the topic in SO, I agree that you should switch to MinGW64 as suggested by the answers there. As a plus, you’ll be able to compile 64-bit programs.

I added ‘-std=c++11’ in the CMakeLists.txt at the root folder like these:
set(CMAKE_CXX_FLAGS “-std=c++11”)
But seems no effect. Can’t see any ‘-std=c++11’ in the generated Makefile

Which toolset are you using?

The gnu c++ from equation. It has MinGW64 underneath it.

Also I found an option in Cmakefiles.txt to switch off logging. Will try switch it off.
option(VTK_ENABLE_LOGGING “Enable logging support.” OFF)

Which Makefile generator did you choose to configure CMake?

Scanning dependencies of target CommonCore
[ 1%] Building CXX object Common/Core/CMakeFiles/CommonCore.dir/vtkArrayIteratorTemplateInstantiate.cxx.obj
[ 2%] Building CXX object Common/Core/CMakeFiles/CommonCore.dir/vtkGenericDataArray.cxx.obj
d:/00prg/gcc/bin/…/lib/gcc/x86_64-w64-mingw32/9.2.0/…/…/…/…/x86_64-w64-mingw32/bin/as.exe: CMakeFiles/CommonCore.dir/vtkGenericDataArray.cxx.obj: too many sections (41279)
C:\Users\ian\AppData\Local\Temp\ccqyCt4W.s: Assembler messages:
C:\Users\ian\AppData\Local\Temp\ccqyCt4W.s: Fatal error: can’t write 101 bytes to section .text of CMakeFiles/CommonCore.dir/vtkGenericDataArray.cxx.obj because: ‘File too big’
d:/00prg/gcc/bin/…/lib/gcc/x86_64-w64-mingw32/9.2.0/…/…/…/…/x86_64-w64-mingw32/bin/as.exe: CMakeFiles/CommonCore.dir/vtkGenericDataArray.cxx.obj: too many sections (41279)
C:\Users\ian\AppData\Local\Temp\ccqyCt4W.s: Fatal error: can’t close CMakeFiles/CommonCore.dir/vtkGenericDataArray.cxx.obj: File too big
make[2]: *** [Common/Core/CMakeFiles/CommonCore.dir/build.make:83: Common/Core/CMakeFiles/CommonCore.dir/vtkGenericDataArray.cxx.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:1453: Common/Core/CMakeFiles/CommonCore.dir/all] Error 2
make: *** [makefile:141: all] Error 2

‘File too big’. Have to find out this now.

Oh… I see you chose “Unix Makefiles”

Need this switch now:


From the errors, you need to enable “big object” support: -Wa,-mbig-obj (GNU) or /bigobj (Visual Studio). These can be set in your CMAKE_CXX_FLAGS and CMAKE_C_FLAGS CMake variables.

– Performing Test EIGEN_COMPILER_SUPPORT_CPP11 - Failed
– Performing Test standard_math_library_linked_to_automatically
– Performing Test standard_math_library_linked_to_automatically - Failed
– Performing Test standard_math_library_linked_to_as_m
– Performing Test standard_math_library_linked_to_as_m - Failed
CMake Error at ThirdParty/eigen/vtkeigen/CMakeLists.txt:123 (message):
Can’t link to the standard math library. Please report to the Eigen
developers, telling them about your platform.

Configuring incomplete.

Make sure the Eigen third party source is of the latest version. There is a recent bug in one of its CMake files: .

This issue cmake failure Can’t link to the standard math library (#538) · Issues · libeigen / eigen · GitLab

But VtK-9.0.1/ThirdParty/eigen is an old simplified version. New version eigen is a bit hard to build.

Well, if upgrading (the recommended action to fix the bug) is not an option, then you can try tweaking Eigen’s CMake script that come with VTK: cmake/FindStandardMathLibrary.cmake:

I can compile that little program, but still got that error. I left a comment under that issue.

Bypassing this check, I finished to configure.

I use :
set (CMAKE_CXX_FLAGS “-std=c++0x -Wa -mbig-obj”)

When Make, got an error:

[  1%] Building CXX object Utilities/KWSys/vtksys/CMakeFiles/vtksys.dir/Directory.cxx.obj
g++.exe: error: unrecognized command line option '-Wa'; did you mean '-W'?
g++.exe: error: unrecognized command line option '-mbig-obj'
make[2]: *** [Utilities/KWSys/vtksys/CMakeFiles/vtksys.dir/build.make:153: Utilities/KWSys/vtksys/CMakeFiles/vtksys.dir/Directory.cxx.obj] Error 1

Searching for -mbig-obj, got this:
c++ - GCC equivalent of MS’s /bigobj - Stack Overflow

Change ‘-Wa -mbig-obj’ with ‘-O1’, the Make can keep going.

I recommend you to use MinGW64 instead of MinGW. MinGW64 supports -Wa -mbig-obj. I use it myself. Home page: .

This eq-gnu compiler I am using has an x86_64-w64-mingw32 sub folder. So it’s also a MINGW.

Running into error with mutex, I decided to give MinGW a go. I downloaded x86_64-posix-sjlj, also I changed to use MinGW generator. Then I finished build VTK.

Also tried to build a test project like this: Help to Build project under WIn 10 - Support - VTK

After changing the setting of RenderingContextOpenGL2 from DEFAULT to YES, I got the project running. This time I changed it by editing the CMakeCache.txt file.

I think the eq-gnu compiler is the same as x86_64-win32-sjlj, but has a newer version c/c++.

It’s good that you managed to compile VTK, but you are restricted to 32-bit binaries with MinGW. MinGW64, despite its name, is a different project and, thus, a different toolset. Alternatively, you can try Visual Studio Community to have 64-bit capability in Windows. With 32-bit, you may run into problems if your project grows by including certain header-only libraries like Boost, Eigen and ExpressTK, as they tend to result in too many symbols in your program, especially in Debug mode. 32-bit programs are also prone to memory fragmentation which is more likely as your scene grows in complexity.