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
In hope of a fix,
Regards.
lassoan
June 14, 2020, 3:03pm
2
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”
The ‘tirpc’ path is specific to Arch.
lassoan
June 14, 2020, 4:07pm
4
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’
1 Like
lassoan
June 14, 2020, 9:26pm
6
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
jcfr
June 15, 2020, 9:47pm
9
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
To learn more about the Slicer fork, read here: https://github.com/Slicer/VTK
lassoan
June 16, 2020, 2:42am
10
@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.
jcfr
June 16, 2020, 1:05pm
11
@lassoan Here is a pull request adding “How to backport changes to a specific branch ?” section to the README. See README: Add "How to backport changes to a specific branch ?" by jcfr · Pull Request #27 · Slicer/VTK · GitHub
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.
jcfr
June 17, 2020, 2:47am
13
Thanks. Both Slicer/VTK fork and Slicer have been updated.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.
