[2251/3142] /usr/bin/x86_64-pc-linux-gnu-g++ -DIOGeometry_EXPORTS -DVTK_IN_VTK -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/IO/Geometry -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/IO/Geometry -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/DataModel -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/DataModel -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/Math -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/Math -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/Transforms -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/Transforms -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/ExecutionModel -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/ExecutionModel -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/IO/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/IO/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/IO/Legacy -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/IO/Legacy -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/Misc -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/Misc -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Common/System -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Common/System -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Filters/General -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Filters/General -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Filters/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Filters/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Filters/Hybrid -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Filters/Hybrid -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Filters/Geometry -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Filters/Geometry -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Imaging/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Imaging/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/IO/Image -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/IO/Image -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Rendering/Core -I/var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Rendering/Core -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Utilities/KWIML -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Utilities/KWIML -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/Utilities/KWSys -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/Utilities/KWSys -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/ThirdParty/jsoncpp -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/ThirdParty/jsoncpp -isystem /usr/include/jsoncpp -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/vtk-9.0.1_build/ThirdParty/zlib -isystem /var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/ThirdParty/zlib -pipe -march=native -fno-diagnostics-color -O2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -std=c++11 -MD -MT IO/Geometry/CMakeFiles/IOGeometry.dir/vtkChacoReader.cxx.o -MF IO/Geometry/CMakeFiles/IOGeometry.dir/vtkChacoReader.cxx.o.d -o IO/Geometry/CMakeFiles/IOGeometry.dir/vtkChacoReader.cxx.o -c /var/tmp/portage/sci-libs/vtk-9.0.1/work/VTK-9.0.1/IO/Geometry/vtkChacoReader.cxx ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_gnome-j3-20210816-092520 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.2.0 * clang version 12.0.1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/12/bin /usr/lib/llvm/12 12.0.1 Python 3.9.6 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.54.0 * The following VMs are available for generation-2: Available Java Virtual Machines: (none found) The Glorious Glasgow Haskell Compilation System, version 8.10.4 HEAD of ::gentoo commit 65de8dd16a78251f9a028ab2c6cce7283459f43c Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Thu Aug 19 19:21:53 2021 +0000 2021-08-19 19:21:52 UTC emerge -qpvO sci-libs/vtk [ebuild N ] sci-libs/vtk-9.0.1 USE="X json odbc openmp qt5 rendering -all-modules -boost -cuda -doc -examples -ffmpeg -gdal -imaging -java -kits -mpi -mysql -offscreen -pegtl -postgres -python -tbb -test -theora -tk -views -web" PYTHON_SINGLE_TARGET="python3_9 -python3_8" VIDEO_CARDS="-nvidia"
Created attachment 734434 [details] emerge-info.txt
Created attachment 734437 [details] emerge-history.txt
Created attachment 734440 [details] environment
Created attachment 734443 [details] etc.portage.tar.bz2
Created attachment 734446 [details] logs.tar.bz2
Created attachment 734449 [details] sci-libs:vtk-9.0.1:20210819-203804.log.bz2
Created attachment 734452 [details] temp.tar.bz2
The issue seems to originate from that the ebuild for hdf5-1.12.1 has switched from the plain configure+make build system to cmake. The latter appends a '-shared' suffix to all installed binaries, the former does not. The suffix is hardcoded into all the CMakeLists.txt files (and manually removing it has been unsuccessful so far, a simple find+sed sadly breaks more than it fixes). The confusingly named 'ONLY_SHARED_LIBS' does not remove the suffix (though imo that sounds like the option that *should* do this). Both Arch and NixOS still use the plain configure+make build system for hdf5, so maybe we should too? CC'ing @marecki since they added the hdf5-1.12.1 ebuild, is there any particular reason for the switch to cmake, or can we just switch it back to fix this issue? (Some other packages are also failing to compile with hdf5-1.12.1, and I have a strong suspicion those failures have a similar cause)
(In reply to Andrew Ammerlaan from comment #8) > The issue seems to originate from that the ebuild for hdf5-1.12.1 has > switched from the plain configure+make build system to cmake. The latter > appends a '-shared' suffix to all installed binaries, the former does not. Umm, no: $ ls /usr/lib64/libhdf5*.so libhdf5.so libhdf5_hl.so libhdf5_tools.so (this is for a build without C++ or Fortran bindings) Moreover, both pkgconfig files and hdf5-targets-gentoo.cmake point at correct libraries - so it's rather interesting why vtk is trying to use CMake target names as library names instead of letting cmake resolve those targets. > CC'ing @marecki since they added the hdf5-1.12.1 ebuild, is there any > particular reason for the switch to cmake, or can we just switch it back to > fix this issue? Try emerging hdf5 (or even just running src_configure for it) with cmake, note how long it takes. Then do the same with autoconf. Extra points for trying this on arm, arm64 or riscv. > (Some other packages are also failing to compile with hdf5-1.12.1, and I > have a strong suspicion those failures have a similar cause) You might want to have a look at the upstream API-incompatibility notes for 1.12, which have been linked to several of the relevant tickets.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0df6c00546a4096f2702623024a232f2da484cc9 commit 0df6c00546a4096f2702623024a232f2da484cc9 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2021-08-27 20:21:11 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2021-08-27 20:23:03 +0000 sci-libs/vtk: add version 9.0.3 Bug: https://bugs.gentoo.org/809209 Package-Manager: Portage-3.0.22, Repoman-3.0.3 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> sci-libs/vtk/Manifest | 4 + sci-libs/vtk/vtk-9.0.3.ebuild | 558 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 562 insertions(+)
Currently working on packaging 9.1.0 which throws a similar error with their (bundled) exodusII library. Interestingly, their bundled hdf5 library is of version 1.12.1, so it's safe to assume, that the package (at least 9.1.0) should build against this version.
(In reply to Bernd from comment #11) > Currently working on packaging 9.1.0 which throws a similar error with their > (bundled) exodusII library. Interestingly, their bundled hdf5 library is of > version 1.12.1, so it's safe to assume, that the package (at least 9.1.0) > should build against this version. When working around bug #833943, sci-libs/vtk-9.1.0 builds fine with sci-libs/hdf5-1.12.1-r1.
This is the dirty workaround I employ: cmake_src_configure einfo "Sed -shared out of build.ninja" sed -i -e 's/lhdf5-shared/lhdf5/g' ${WORKDIR}/${PN}-${PV}_build/build.ninja || die "Sed -lhdf5-shared -> -lhdf5 failed!" sed -i -e 's/lhdf5_hl-shared/lhdf5_hl/g' ${WORKDIR/}/${PN}-${PV}_build/build.ninja || die "Sed -lhdf5_hl-shared -> -lhdf5_hl failed!"
Wouldn't patching the netCDFTargets.cmake file post install be a better workaround for this, until upstream has fixed the issue?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7fa499da25bf08098ba57a7421129c9288443de4 commit 7fa499da25bf08098ba57a7421129c9288443de4 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2022-05-18 16:56:56 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2022-05-18 16:58:47 +0000 sci-libs/vtk: unrestrict hdf5 The issue was never in vtk, it was in netcdf which has been fixed. Compiles without problems now. Bug: https://bugs.gentoo.org/833943 Closes: https://bugs.gentoo.org/834087 Closes: https://bugs.gentoo.org/809209 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> sci-libs/vtk/{vtk-9.1.0-r1.ebuild => vtk-9.1.0-r2.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
