Build failure in PITTNullCode SphericalHarmonicReconGen

[Wolfgang Kastaun]

Building a freshly downloaded ET, I get the following:

/kalahari/users/smeagol/ET/Lorentz/Cactus/configs/pull8try/build/SphericalHarmonicReconGen/sph_database.cc:975:34: error: invalid conversion from ‘herr_t (*)(hid_t, const char*, const H5L_info1_t*, void*)’ {aka ‘int (*)(long int, const char*, const H5L_info1_t*, void*)’} to ‘H5L_iterate2_t’ {aka ‘int (*)(long int, const char*, const H5L_info2_t*, void*)’} [-fpermissive]
  975 |    HDF5_ERROR(H5Literate_by_name (file, varname_table[0][0].c_str(),
      |                                  ^
      |                                  |
      |                                  herr_t (*)(hid_t, const char*, const H5L_info1_t*, void*) {aka int (*)(long int, const char*, const H5L_info1_t*, void*)}

Compiler: gcc 11.1.0

OS: Arch linux

[Roland Haas]

Might be a bug in HDF5. Is this HDF5 1.12? See https://github.com/rhaas80/ExternalLibraries-Silo/commit/c2f67165841b35467b94ce270b4db34746cf626b .

Can you try adding:

CPPFLAGS=-DH5Oget_info_vers=1 -DH5O_info_t_vers=1

to your option list, please?

Probably should go into a patch for the included tarball of the ET so that at least our self-built HDF5 is bug free (even if a system installed one would not be).

[Roland Haas]

See also (I think) https://github.com/ornladios/ADIOS2/issues/2083 https://github.com/spack/spack/issues/15553

[Wolfgang Kastaun]

I confirm that the problem is HDF5 version 1.12.0. I was not using the bundled ET HDF5 but the one installed on the OS (Arch Linux). On the HDF groups website this version is announced as major release that breaks backwards compatibility.

Adding the suggested CPPFLAGS did not solve the problem (the rest of the optionlist is identical to ET’s generic.cfg). I note that the flags suggested on the HDF webpage

https://www.hdfgroup.org/2020/03/release-of-hdf5-1-12-0-newsletter-172/

are different from the ones suggested above, but I did not try those yet.

‌

[Roland Haas]

Interesting. Ok. The Silo one is an actual bug in HDF5 since it’s symbols are not internally consistent. This one here may be different though even so the newsletter “[…]that includes deprecated symbols (the default)[…]” to me would read as if the default settings should be a backwards compatible API (which of course Arch Linux may change if they want to be on the bleading edge).

I will give this a try on my workstation with a self-compiled HDF5 1.12.

Semantic versioning by HDF5 would be great so that API change → major version change. But then, with the Linux kernel now also updating major version numbers when the devs run out of fingers and toes to count, this is probably a futile hope…

[Roland Haas]

Hmm, correction, if I build my hdf5-1.12.0.tar.gz tarball without options it does default H5_USE_112_API_DEFAULT ie the new API is used by default. I get no breakage though.

Looking at the source code, the function in question (H5iter) is declared as:

herr_t SPH_db_SpEC_H5::H5iter(hid_t loc_id, const char* name, const H5L_info_t* info, void* operator_data)

i.e. it takes a H5L_info_t and inconsistencies in type would be blamed on HDF5.

I cannot make it actually fail though. Even with gcc-11 and a self-compiled HDF5 1.12.0. I tried no options. -with-default-api-version=v110 and -with-default-api-version=v18 all let me compile the ET without issue.

[Wolfgang Kastaun]

Changing only HDF5_DIR=BUILD, it build without problem. So it is not a problem connected to the compiler. Maybe the Arch Linux hdf5 package is simply messed up.

[Roland Haas]

Sounds like it to me. I tried installing Arch in a virtual machine but its installation procedure defeats me. It has been a long time since I last had to run grub-install and bootstrap a Linux installation from scratch. Arch is too much down-on-your-knees-in-the-muck for me :-). I may try a Docker image if there exists one, or is there is a simpler installation instruction than the official “Installation guide” (which as far as I can tell is faulty right now since SHELL defaults to zsh but their instruction do not pacstrap zsh into the installed system).
Do you know the exact version number that Arch installed 1.12.0 exactly? And there were no other leftover HDF5 packages around?

In principle I would want to know why this fails and if there is something we can do to avoid this on Arch (and maybe similar systems in the future), but without being able to reproduce the issue this is hard.

[Roland Haas]

Cannot reproduce due to lack of arch Linux. Seems to be an issue in the Linux/GNU distro and not in the ET.