Thank you. And thanks for the tip about set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Og"). I'm surprised that this is necessary. This may be turning off a lot of optimizations. I wonder if there's another way to make your system happy with the large file size?

Also, do C++11 threads not work on Windows? I was under the impression that standard was well supported.

Also, do C++11 threads not work on Windows? I was under the impression that standard was well supported.

I was reluctant to install Microsoft Visual Studio Compiler. So I tried to build libigl with MingW. On Windows 10, w64devkit passes the tests successfully. Here is what I am referring to:

[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
[cmake] -- Found Threads: TRUE

I also tried MingW builds but it would not pass the above tests.
The following paragraph is quoted from MingW builds page:

GCC with the MCF thread model

GCC with the MCF thread model is a series of x86 and x64 native toolchains built by LH_Mouse. The MCF thread model involves the mcfgthread library to provide minimum yet complete C++11 thread support. Disregarding POSIX or Windows XP compatibility, it implements (hopefully the most) efficient mutexes and condition variables that are competitive with even native slim reader/write (SRW) locks and condition variables since Windows Vista.

However, I still cannot figure out why the tests do not pass for MingW builds.

Thank you. And thanks for the tip about set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Og"). I'm surprised that this is necessary. This may be turning off a lot of optimizations. I wonder if there's another way to make your system happy with the large file size?

I have not yet found an alternative solution. It seems there are reports of the same issue for building other libraries with MingW. For example, here.

Libigl example project builds successfully by the fix, that is #include <cstdint>. It seems there are some other files that require the line #include <cstdint>. I found this out while building Example 201.

In addition, this might be irrelevant but while following libigl tutorials I found lines like this TUTORIAL_SHARED_PATH "/fandisk.off",V,F); which require libigl data . However, nothing is mentioned about the location of libigl data in the tutorials page. It would be nice to add a link to libigl data and some explanations.

Thanks.

Did you try the -Wa,-mbig flags mentioned in the link you sent?

The cmake build system should be downloading the tutorial data automatically. It should get put in libigl/tutorial/data

Thanks.

Did you try the -Wa,-mbig flags mentioned in the link you sent?

The cmake build system should be downloading the tutorial data automatically. It should get put in libigl/tutorial/data

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wa,-mbig") worked for me after a clean rebuild (It took some time to build, Build completed: 00:11:08.439). Here is a complete report:

[build] [10/20   5% :: 2.620] Building C object _deps/glad-build/CMakeFiles/glad.dir/src/glad.c.obj
[build] [11/20  10% :: 3.187] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/init.c.obj
[build] [12/20  15% :: 3.251] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/context.c.obj
[build] [13/20  20% :: 3.291] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/vulkan.c.obj
[build] [14/20  25% :: 3.402] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/win32_joystick.c.obj
[build] [15/20  30% :: 3.513] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/window.c.obj
[build] [16/20  35% :: 3.531] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/monitor.c.obj
[build] [17/20  40% :: 3.541] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/win32_init.c.obj
[build] [18/20  45% :: 3.591] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/input.c.obj
[build] [18/20  50% :: 4.142] Linking C static library lib\libglad.a
[build] [18/20  55% :: 6.114] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/win32_time.c.obj
[build] [18/20  60% :: 6.129] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/win32_monitor.c.obj
[build] [18/20  65% :: 6.210] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/win32_thread.c.obj
[build] [18/20  70% :: 6.403] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/osmesa_context.c.obj
[build] [18/20  75% :: 6.465] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/wgl_context.c.obj
[build] [18/20  80% :: 6.520] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/egl_context.c.obj
[build] [18/20  85% :: 6.534] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/win32_window.c.obj
[build] [19/20  90% :: 6.736] Linking C static library lib\libglfw3.a
[build] [19/20  95% :: 76.363] Building CXX object CMakeFiles/example.dir/main.cpp.obj
[build] [20/20 100% :: 668.097] Linking CXX executable example.exe
[driver] Build completed: 00:11:08.439

Regarding the compiler flag -Og, it seems it does some optimization. Here is the link. I also tested -O1 and -O2 flags and they did actually work. I would be happy to know how much performance boost would be gained by using -Wa,-mbig flags instead of -Og. (Don't even know how one would go for benchmarking Libigl for such cases)