GLM in Manjaro isn't found even though it's installed system-wide (via package)

[neurodiverseEsoteric]

CMake Error at CMakeLists.txt:59 (MESSAGE):
Please point the environment variable GLM_INCLUDE_DIR to the root directory
of your GLM installation.

[YING WANG]

Thanks for the info!
We just updated the CMakeLists.txt. Could you pull the latest version and try it again?
If GLM is still not found, you can customize by either adding the following line:SET(GLM_ROOT_DIR "/path/to/dir")in CMakeLists.txt, or adding your path in cmake/FindGLM.cmake.
Feel free to let me know whether it works or not.

[neurodiverseEsoteric]

It worked when I added a '/' at the end of every line mentioning a directory in every file ('/usr/include/' vs the not working '/usr/include'), but now there's a new compiler error:

[redmaxRootDir]redmax/c++/PCG/src/RigidBodyMain.cpp:301:18: error: ‘reinterpret_pointer_cast’ is not a member of ‘std’
             std::reinterpret_pointer_cast<Elastic>(LS->constraints[i])->initLengthToRest(LS, S);
                  ^~~~~~~~~~~~~~~~~~~~~~~~

[redmaxRootDir]/redmax/c++/PCG/src/RigidBodyMain.cpp:301:18: note: suggested alternative: ‘const_pointer_cast’
             std::reinterpret_pointer_cast<Elastic>(LS->constraints[i])->initLengthToRest(LS, S);
                  ^~~~~~~~~~~~~~~~~~~~~~~~
                  const_pointer_cast

[redmaxRootDir]/redmax/c++/PCG/src/RigidBodyMain.cpp:301:50: error: expected primary-expression before ‘>’ token
             std::reinterpret_pointer_cast<Elastic>(LS->constraints[i])->initLengthToRest(LS, S);

[redmaxRootDir]/redmax/c++/PCG/src/RigidBodyMain.cpp:301:73: error: ‘using element_type = class Constraint’ {aka ‘class Constraint’} has no member named ‘initLengthToRest’
             std::reinterpret_pointer_cast<Elastic>(LS->constraints[i])->initLengthToRest(LS, S);

Also can PARDISO be removed? There's no free license for it if you don't have an .edu email address...

[YING WANG]

Thanks for the feedback! I modified the path in every file.

• reinterpret_pointer error:
  It looks like std::reinterpret_pointer_cast is not available. I made some change based on https://riptutorial.com/cplusplus/example/15335/casting-std--shared-ptr-pointers

• PARDISO library:
  Including PARDISO library is optional right now. You may turn it on later in CMakeLists.txt. However, I would strongly recommend you to include PARDISO if you want to reproduce some results in the paper.

[neurodiverseEsoteric]

Thanks again, though I had to make a few more tweaks to certain names of libraries and directories that might be specific to Arch Linux (Manjaro), and I had to run cmake like this:
EIGEN3_INCLUDE_DIR="/usr/include/eigen3" cmake ../

...Which sucessfully creates the build files (which I decided to run make on after I post this)

Here are the cmake config files in question...

cmake.zip

[neurodiverseEsoteric]

[100%] Linking CXX executable RedMaxPCG
/usr/bin/ld: CMakeFiles/RedMaxPCG.dir/src/main.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: /usr/lib/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/RedMaxPCG.dir/build.make:433: RedMaxPCG] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/RedMaxPCG.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

[YING WANG]

Could you try replacing line 309 in CMakeLists.txt
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall -pedantic")
by
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall -pedantic -pthread")?
I am not sure if it would work.

I will test the code in Linux in a few days. I hope I can fix these errors at that point.

[neurodiverseEsoteric]

Thanks, the linking is tantalizingly close, but MKL seems to be broken as well, both with/without PARDISO enabled...

[neurodiverseEsoteric]

Never mind the last bit, it appears I needed to add some more flags from https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ to get MKL to work properly

[neurodiverseEsoteric]

Finally got it to build and run...also had to switch GLFW libs regarding another Arch-related issue: JuliaGL/GLFW.jl#112

[YING WANG]

Thanks! It is very helpful! I will definitely incorporate these Arch-related changes in our code.