HDF5 version detection is broken (upstream bug)

[hmenke]

Prerequisites

• [x] Please check that a similar issue isn't already filed: https://github.com/issues?q=is%3Aissue+user%3Atriqs

Description

The HDF5 version detection is broken in CMake since HDF5 started adding “subrelease” versions. For example on a system with HDF5 1.14.1-2 I see

-- -------- HDF5 detection -------------                                                                                      
-- HDF5 C compiler wrapper is unable to compile a minimal HDF5 program.                                                       
-- Found HDF5: /mpcdf/soft/RHEL_9/packages/znver4/hdf5/gcc_14-14.1.0/1.14.1/lib/libhdf5.so (found version "") found components: C HL

Note the empty (found version ""). There was an attempt to fix this upstream, but the fix was faulty as well, see my comment at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9476#note_1549674

And since HDF5_VERSION remains unset, all of these preprocessor defines are not applied and therefore result in compiler errors at build time.

https://github.com/TRIQS/h5/blob/18c560f0595cf3f11e9536cfdc6e3aff0bd23cf1/c%2B%2B/h5/CMakeLists.txt#L48-L53

Steps to Reproduce

1. Compile h5 on a system with HDF5 including a subrelease version.

Expected behavior: h5 compiles or maybe a configuration error because HDF5_VERSION is unset.

Actual behavior: Compiler errors, because preprocessor defines are missing.

Versions

https://github.com/TRIQS/h5/commit/18c560f0595cf3f11e9536cfdc6e3aff0bd23cf1

Formatting

Please use markdown in your issue message. A useful summary of commands can be found here.

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

[hmenke]

Workaround: If it is known that the HDF5 version detection is broken on the local system, pass the necessary compiler flags manually.

CXXFLAGS="-DH5_USE_110_API -DH5_VER_GE_113" cmake ...

[HugoStrand]

@hmenke, thank you for reporting. I am hit by the same issue and I am currently using the same workaround to be able to use triqs/3.3.x et al.

[Wentzell]

Thank you @hmenke for pointing this out. I drafted a solution on the branch https://github.com/TRIQS/h5/tree/DEV_H5SUBV_ISSUE Can you please try this?