Compilation issues on RHEL with GCC 10.3.0 and VTK 9.0.1

[lennartvi]

When compiling from source using CMake on Red Hat Enterprise Linux, I ran into some problems after our HPC software environment was updated to new GCC and VTK versions. Previously, compilation on this system worked well for GCC 9.3.0 and VTK 8.2.0. Trying to compile with GCC 10.3.0 and VTK 9.0.1 gave me two distinct errors in the make process, copied below.

For GCC 10.3.0, I used the Fortran compiler -std=legacy flag to convert errors from the Fortran code into warnings, but compilation then got stuck when the svsolver executable was being built.

System overview

• OS: Red Hat Enterprise Linux 8.4
• GCC compiler: GCC 10.3.0
• Fortan compiler: mpifort (mpif90)
• Fortran compiler flag FFLAGS=-std=legacy

Software

• CMake 3.20.1
• OpenMPI 4.1.1
• VTK 9.0.1 (foss toolchain, local install)

svSolver

• svSolver sourcecode version Jul 22, 2022
• CMake flag SV_USE_LOCAL_VTK=ON

During the make process, this first gave a problem when linking to the VTK binaries, as copied below.

[ 43%] Linking CXX executable ../../../bin/svpost
cd /home/lvdvelde/bin/svSolver/svSolver-build/svSolver-build/FlowSolvers/ThreeDSolver/svPost && /gpfs/admin/_hpc/sw/arch/AMD-ZEN2/Centos8/EB_production/2021/software/CMake/3.20.1-GCCcore-10.3.0/bin/cmake -E cmake_link_script CMakeFiles/svpost.dir/link.txt --verbose=1
/sw/arch/Centos8/EB_production/2021/software/GCCcore/10.3.0/bin/c++ -fpermissive -O2 -g -DNDEBUG -rdynamic CMakeFiles/svpost.dir/post_solver.cxx.o -o ../../../bin/svpost ../../../lib/lib_simvascular_thirdparty_zlib.a /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkFiltersFlowPaths-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkFiltersModeling-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkChartsCore-9.0.so.9.0.1 ../../../lib/lib_simvascular_solverio.a /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkRenderingContext2D-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkRenderingCore-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkIOXML-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkIOXMLParser-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkFiltersGeneral-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkFiltersCore-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonComputationalGeometry-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkIOLegacy-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkIOCore-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonExecutionModel-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonDataModel-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonTransforms-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonMisc-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonMath-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtkCommonCore-9.0.so.9.0.1 /sw/arch/Centos8/EB_production/2021/software/VTK/9.0.1-foss-2021a/lib/libvtksys-9.0.so.9.0.1 -ldl ../../../lib/lib_simvascular_thirdparty_zlib.a -lmpi
/home/lvdvelde/bin/svSolver/Code/FlowSolvers/ThreeDSolver/svPost/post_solver.cxx:3283: error: undefined reference to 'vtkGeometryFilter::New()'
/home/lvdvelde/bin/svSolver/Code/FlowSolvers/ThreeDSolver/svPost/post_solver.cxx:3351: error: undefined reference to 'vtkGeometryFilter::New()'
collect2: error: ld returned 1 exit status
make[5]: *** [FlowSolvers/ThreeDSolver/svPost/CMakeFiles/svpost.dir/build.make:119: bin/svpost] Error 1
make[5]: Leaving directory '/gpfs/home1/lvdvelde/bin/svSolver/svSolver-build/svSolver-build'
make[4]: *** [CMakeFiles/Makefile2:528: FlowSolvers/ThreeDSolver/svPost/CMakeFiles/svpost.dir/all] Error 2
make[4]: Leaving directory '/gpfs/home1/lvdvelde/bin/svSolver/svSolver-build/svSolver-build'
make[3]: *** [Makefile:136: all] Error 2
make[3]: Leaving directory '/gpfs/home1/lvdvelde/bin/svSolver/svSolver-build/svSolver-build'
make[2]: *** [CMakeFiles/svSolver.dir/build.make:86: svSolver-prefix/src/svSolver-stamp/svSolver-build] Error 2
make[2]: Leaving directory '/gpfs/home1/lvdvelde/bin/svSolver/svSolver-build'
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/svSolver.dir/all] Error 2
make[1]: Leaving directory '/gpfs/home1/lvdvelde/bin/svSolver/svSolver-build'
make: *** [Makefile:91: all] Error 2

I have found some similar error codes for VTK linking at https://discourse.slicer.org/t/build-fails-in-vtk-many-undefined-references/12150. A possible solution there was to turn off libssh2 in External_curl.cmake, but I am unsure if this helps and how to implement this option in my compilation configuration.
When reverting to an older VTK version (VTK-8.2.0), this error no longer disappeared.

---

With VTK-8.2.0 and GCC-10.3.0 (and the -std=legacy Fortran flag), I got the following error in a subsequent step of the compilation.

[ 65%] Building CXX object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/Cinput.cxx.o
[ 65%] Building CXX object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/ValType.cxx.o
[ 66%] Building CXX object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/input_fform.cxx.o
[ 66%] Building CXX object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/partition.cxx.o
[ 66%] Building CXX object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/main.cxx.o
[ 67%] Building CXX object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/use_vtk.cxx.o
[ 67%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/getIntPnts.c.o
[ 68%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/ShapeFunctions_uniformP.c.o
[ 68%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/shptet.c.o
[ 69%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/symtri.c.o
[ 69%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/symtet.c.o
[ 70%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/write_restart_files.c.o
[ 70%] Building C object FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/tmrc.c.o
[ 70%] Linking CXX executable ../../../bin/svsolver
/sw/arch/Centos8/EB_production/2021/software/binutils/2.36.1-GCCcore-10.3.0/bin/ld.gold: error: CMakeFiles/svsolver.dir/write_restart_files.c.o: multiple definition of 'cvsolver_iotype'
/sw/arch/Centos8/EB_production/2021/software/binutils/2.36.1-GCCcore-10.3.0/bin/ld.gold: CMakeFiles/svsolver.dir/main.cxx.o: previous definition here
collect2: error: ld returned 1 exit status
make[5]: *** [FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/build.make:340: bin/svsolver] Error 1
make[4]: *** [CMakeFiles/Makefile2:645: FlowSolvers/ThreeDSolver/svSolver/CMakeFiles/svsolver.dir/all] Error 2
make[3]: *** [Makefile:136: all] Error 2
make[2]: *** [CMakeFiles/svSolver.dir/build.make:86: svSolver-prefix/src/svSolver-stamp/svSolver-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/svSolver.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

From what I can understand, there appears to be an ambiguous definition of cvsolver_iotype in write_restart_files.c.o and main.cxx.o?

This error was resolved when I used GCC 9.3.0. So using GCC 9.3.0 and VTK 8.2.0 fixed the issues for me, but would be great for future compatibility if new versions are supported.

[ktbolt]

@lennartvi I'm not sure what's going on with error: undefined reference to vtkGeometryFilter::New(). Let me build a RHEL VM and so if I can reproduce the error.

For the cvsolver_iotype error you can just comment out the main.cxx:char cvsolver_iotype[80] statement. The newer compiler versions are becoming stricter, which is good and bad! I will open an Issue for this.

[lennartvi]

Hi Dave, thanks for the tip! I had to recompile the solver this week and commenting out the cvsolver_iotype indeed allowed successful compilation with GCC10.

If you have any update on the VTK error, would be happy to learn more.

Best, Lennart