-- _versionComponents=1;12;1 -- HDF5_VERSION=1.12.1 CMake Error at config/cmake_files/medMacros.cmake:451 (MESSAGE): HDF5 version is 1.12.1. Only versions >= 1.10.2 are supported. Call Stack (most recent call first): CMakeLists.txt:113 (MED_FIND_HDF5) ------------------------------------------------------------------- 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 c26b69a42312c3e5967877acbbb1e4e65c210e67 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Aug 18 22:21:35 2021 +0000 2021-08-18 22:21:34 UTC emerge -qpvO sci-libs/med [ebuild N ] sci-libs/med-4.1.0 USE="fortran -doc -mpi -python -test" PYTHON_SINGLE_TARGET="python3_9 -python3_8"
Created attachment 734050 [details] emerge-info.txt
Created attachment 734053 [details] CMakeOutput.log
Created attachment 734056 [details] emerge-history.txt
Created attachment 734059 [details] environment
Created attachment 734062 [details] etc.portage.tar.bz2
Created attachment 734065 [details] logs.tar.bz2
Created attachment 734068 [details] sci-libs:med-4.1.0:20210818-233310.log
Created attachment 734071 [details] temp.tar.bz2
Same here
Ditto
Even ignoring the version make check, sci-libs/med fails to compile if sci-libs/hdf5 is not installed with the 0/1.10.5 subslot. Installing =sci-libs/hdf5-1.10.5-r1 and sci-libs/med compiles successfully.
Created attachment 734884 [details, diff] Patch to compile med-4.1.0 with hdf5-1.12
Arch linux had a patch but that was not enough. Weirdly, the generated H5versions.h for hdf5 required setting 16 and 18 API versions so all the required functions are defined. I cannot compile with mpi support on my machine so the mpi is untested.
Thanks for the patch, fixes the problem on my system. This bug should also block hdf5-1.12 #808733
In the patch, the lines which check for H5_VERS_MINOR seem to be redundant. 12 is greater than 10, so IMO there's no need to change these lines. I'm already working on a patch, to change the function calls, which have changed with hdf5 v1.12.
Didn't pay enough attention to the error lines following the H5_VERS_MINOR, so these are indeed needed. But I'm not sure if this is correct and med actually implements 1.8 API. It should, however, or else they need to change a lot of their functions. I didn't need the line changing hversionMMR in MedfileCompatibility.c, however and we don't need to change the lines for the autotools files, which we don't use anymore.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=350ea3e89d0e87e35a3a4b5f2ce92b55aae9d226 commit 350ea3e89d0e87e35a3a4b5f2ce92b55aae9d226 Author: Bernd Waibel <waebbl-gentoo@posteo.net> AuthorDate: 2021-08-24 15:45:11 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2021-08-25 06:13:24 +0000 sci-libs/med: fix build against hdf5-1.12 Thanks to Alexandre Ferreira for providing the patch. Closes: https://bugs.gentoo.org/809008 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Bernd Waibel <waebbl-gentoo@posteo.net> Closes: https://github.com/gentoo/gentoo/pull/22096 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> .../med-4.1.0-0003-build-against-hdf5-1.12.patch | 117 +++++++++++++++++++++ sci-libs/med/med-4.1.0.ebuild | 6 +- 2 files changed, 121 insertions(+), 2 deletions(-)
Re-opening this. The PR has to be reverted, as it breaks sci-libs/gmsh without the CI reporting it before it was merged.
The package falls back to using hdf5-1.10 whenever USE=mpi is provided, so there's no need to mask the mpi use flag on med. The ebuild itself builds, only the package.use.mask change happened to introduce the break in ::gentoo. Closing this bug.
