Build error with emscripten/clang

[cmmw]

Compiling with emscripten (clang 18.0.0) on Windows does not work. An error about a supposedly wrong C++ version is reported:

setup.hpp:640:3: error: 'constexpr' specifier is incompatible with C++98 [-Werror,-Wc++98-compat]
640 | constexpr std::size_t countof(T const (&)[N])

even though -std=c++20 is used:

em++.bat -DGLM_FORCE_CXX17 -IE:/projects/wasm-test/cmake-build-debug/_deps/glm-src -g -std=c++17 -fcolor-diagnostics -Wno-c++98-compat -Wno-c++98-compat-pedantic -Werror -Weverything -MD -MT _deps/glm-build/glm/CMakeFiles/glm.dir/detail/glm.cpp.o -MF _deps\glm-build\glm\CMakeFiles\glm.dir\detail\glm.cpp.o.d -o _deps/glm-build/glm/CMakeFiles/glm.dir/detail/glm.cpp.o -c E:/projects/wasm-test/cmake-build-debug/_deps/glm-src/glm/detail/glm.cpp

With GLM_ENABLE_CXX_17 set to ON, the compilation will continue until the next error is reported:

func_packing.inl:20:3: error: unsafe buffer access [-Werror,-Wunsafe-buffer-usage]
20 | u.in[1] = result[1];

It turns out that the problem with clang are the strict complie options at line 244 in the CMakeLists.txt file.

Compilation works when removing these options.

Now my question: is this done on purpose? Until now I only used glm with gcc/mingw without any problems. Unfortunately, I only have the clang compiler within emscripten at hand and cannot test it with the plain clang compiler.

[tez011]

I would like to bump this and add to the conversation:

While compiling glm 1.0.0 on MacOS with AppleClang 15.0.0 and GLM_ENABLE_CXX_20 set to ON, I'm presented with an error on 'glm.cpp':

error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror, -Wpoison-system-directories]

Additionally, while compiling glm 1.0.0 on Linux with vanilla clang 16.0.6 and GLM_ENABLE_CXX_20 set to ON, I see the same issues as OP in func_packing.inl.

In both cases, for my compilers, merely removing -Weverything from line 244 allows the build to advance. -Werror appears to cause no issue for now.

I am also curious if this was done on purpose, as well as why -Weverything is set for clang but not gcc, intel, or msvc (/Wall is msvc's -Weverything).

[christophe-lunarg]

I would like to bump this and add to the conversation:

While compiling glm 1.0.0 on MacOS with AppleClang 15.0.0 and GLM_ENABLE_CXX_20 set to ON, I'm presented with an error on 'glm.cpp':

error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror, -Wpoison-system-directories]

Additionally, while compiling glm 1.0.0 on Linux with vanilla clang 16.0.6 and GLM_ENABLE_CXX_20 set to ON, I see the same issues as OP in func_packing.inl.

In both cases, for my compilers, merely removing -Weverything from line 244 allows the build to advance. -Werror appears to cause no issue for now.

I am also curious if this was done on purpose, as well as why -Weverything is set for clang but not gcc, intel, or msvc (/Wall is msvc's -Weverything).

It was done only in Clang because it tooks already a lot of time of fixing all the warnings for Clang. But I am hoping to do the same exercices with Visual C++ and GCC at some point even if I expect diminushing returns as with Clang it actually detected some bugs but probably all (most) of them where resolved during that exercice.

I moved the -Weverything to the unit test directory so that it doesn't involved build the library. This way, I am hoping to keep detecting possible issues without breaking the build of projects that depends on the library build.