Build fails in vtkExodus on Linux

Hello,

After today’s pull, build fails on Linux with these messages :

/usr/bin/ld: CMakeFiles/vtkexodusII.dir/src/ex_open_par.c.o:(.rodata+0x0): multiple definition of `exodus_unused_symbol_dummy_1’; CMakeFiles/vtkexodusII.dir/src/ex_create_par.c.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status
make[6]: *** [ThirdParty/exodusII/vtkexodusII/CMakeFiles/vtkexodusII.dir/build.make:4172: lib/libvtkexodusII-8.2.so.1] Error 1
make[5]: *** [CMakeFiles/Makefile2:8028: ThirdParty/exodusII/vtkexodusII/CMakeFiles/vtkexodusII.dir/all] Error 2
make[5]: *** Waiting for unfinished jobs…
make[4]: *** [Makefile:150: all] Error 2
make[3]: *** [CMakeFiles/VTK.dir/build.make:137: VTK-prefix/src/VTK-stamp/VTK-build] Error 2
make[2]: *** [CMakeFiles/Makefile2:1115: CMakeFiles/VTK.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:224: CMakeFiles/Slicer.dir/rule] Error 2

In hope of a fix,

Regards.

If this was not a completely clear build (you updated an existing build tree) then please delete the entire top-level build directory of Slicer and start a new build.

It was indeed a clean build, I forgot this important detail.

Configured and built as such :

export CFLAGS="-I/usr/include/tirpc"
export CXXFLAGS="-I/usr/include/tirpc"
cmake -DSlicer_VTK_VERSION_MAJOR:INT=8 -DQt5_DIR:PATH=/usr/lib/cmake/Qt5 -DBUILD_TESTING:BOOL=OFF -DCMAKE_BUILD_TYPE:STRING=Release -DADDITIONAL_CXX_FLAGS:STRING=-I/usr/include/tirpc …/Slicer
export LANG=C
export LC_ALL=C
make -j6

The ‘tirpc’ path is specific to Arch.
Using GCC 10.1.0, Qt 5.15.0.

It looks like an error caused by gcc tightening some restrictions - https://gitlab.kitware.com/vtk/vtk/-/issues/17774

We plan to upgrade to latest VTK soon. That version will contain the fix. @jcfr do you have an estimation of when the update may happen?

In the meantime, you may backport the fix to Slicer’s VTK or use an older gcc version.

After backporting the available patch to Slicer’s VTK, the build process completes successfully.

For the record, it fails to build after downgrading GCC to 9.2; I suppose it’s related to the GCC version that built Arch’s currently installed libraries.

Thanks.

-************************************************************************-

/usr/bin/ld: /usr/lib/libQt5Widgets.so.5.15.0: undefined reference to std::pmr::monotonic_buffer_resource::~monotonic_buffer_resource()@GLIBCXX_3.4.28' /usr/bin/ld: /usr/lib/libQt5Widgets.so.5.15.0: undefined reference to vtable for std::pmr::monotonic_buffer_resource@GLIBCXX_3.4.28’
collect2: error: ld returned 1 exit status
make[6]: *** [CMakeFiles/CTKAppLauncher.dir/build.make:109: bin/CTKAppLauncher] Error 1
make[5]: *** [CMakeFiles/Makefile2:227: CMakeFiles/CTKAppLauncher.dir/all] Error 2
make[4]: *** [Makefile:172: all] Error 2
make[3]: *** [CMakeFiles/CTKAppLauncherLib.dir/build.make:134: CTKAppLauncherLib-prefix/src/CTKAppLauncherLib-stamp/CTKAppLauncherLib-build] Error 2
make[2]: *** [CMakeFiles/Makefile2:493: CMakeFiles/CTKAppLauncherLib.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs…
Note: switching to ‘3.30.1’.

1 Like

Great, thanks for the update. Could you send a pull request to Slicer’s VTK with the backported fix?

This diff is easily obtained, but never did a pull request anywhere. Anyway, I 'll investigate ASAP, in daylight.

1 Like

The PR process is too heavy for such a trivial patch, I’m posting it here. Anyway, it follows the one you mentioned.

diff --git a/ThirdParty/exodusII/update.sh b/ThirdParty/exodusII/update.sh
index 21b1098191..db2450250a 100755
--- a/ThirdParty/exodusII/update.sh
+++ b/ThirdParty/exodusII/update.sh
@@ -8,7 +8,7 @@ readonly name="exodusII"
 readonly ownership="Seacas Upstream <kwrobot@kitware.com>"
 readonly subtree="ThirdParty/$name/vtk$name"
 readonly repo="https://gitlab.kitware.com/third-party/seacas.git"
-readonly tag="for/vtk-old"
+readonly tag="for/vtk-20200128-7.24f-v2019-12-18"
 readonly paths="
 packages/seacas/libraries/exodus/CMakeLists.vtk.txt
 packages/seacas/libraries/exodus/cmake/exodus_config.h.in
diff --git a/ThirdParty/exodusII/vtkexodusII/src/ex_create_par.c b/ThirdParty/exodusII/vtkexodusII/src/ex_create_par.c
index bf5bb44711..1286074fac 100644
--- a/ThirdParty/exodusII/vtkexodusII/src/ex_create_par.c
+++ b/ThirdParty/exodusII/vtkexodusII/src/ex_create_par.c
@@ -614,5 +614,5 @@ int ex_create_par_int(const char *path, int cmode, int *comp_ws, int *io_ws, MPI
  * Prevent warning in some versions of ranlib(1) because the object
  * file has no symbols.
  */
-const char exodus_unused_symbol_dummy_1;
+const char exodus_unused_symbol_dummy_ex_create_par;
 #endif
diff --git a/ThirdParty/exodusII/vtkexodusII/src/ex_open_par.c b/ThirdParty/exodusII/vtkexodusII/src/ex_open_par.c
index f379fc3496..c568353f52 100644
--- a/ThirdParty/exodusII/vtkexodusII/src/ex_open_par.c
+++ b/ThirdParty/exodusII/vtkexodusII/src/ex_open_par.c
@@ -474,5 +474,5 @@ int ex_open_par_int(const char *path, int mode, int *comp_ws, int *io_ws, float
  * Prevent warning in some versions of ranlib(1) because the object
  * file has no symbols.
  */
-const char exodus_unused_symbol_dummy_1;
+const char exodus_unused_symbol_dummy_ex_open_par;
 #endif

Thanks for the patch.

In fact, this is much simpler.

Could you fork https://github.com/Slicer/VTK ? And publish a Pull Request against the Slicer fork that based on https://github.com/Slicer/VTK/tree/slicer-v8.2.0-2018-10-02-74d9488523 adding the commit ? Once this is done, we will take care of integrating it and updating Slicer.

Thanks for your help :pray:

To learn more about the Slicer fork, read here: https://github.com/Slicer/VTK

@jcfr I find the process described here quite complicated, too. My impression is that a new branch has to be created for each pull request, but it is not clear why or how exactly it should be named.

@lassoan Here is a pull request adding “How to backport changes to a specific branch ?” section to the README. See https://github.com/Slicer/VTK/pull/27

My impression is that a new branch has to be created for each pull request

The introduction of this new README entry should help clarify

it is not clear why or how exactly it should be named

The branch is named after the commit common to both the upstream project and the Slicer fork. It allows to clearly identify the divergence point.

The pull request is visible. I hope it’s rightly done, for something new to me.

Thanks. Both Slicer/VTK fork and Slicer have been updated.
For reference, see https://github.com/Slicer/Slicer/pull/4990

Amongst the many changes in GCC 10, the use of -fno-common by default explains this behaviour. The fix is therefore valid, moreover explained here; except that I don’t know the effect of the ‘tags’ change in the patch.

I am seeing linking issues with GCC 10, despite the patch now, reported here. Going with clang for now.