Build failure in PITTNullCode SphericalHarmonicReconGen

Issue #2572 invalid
Wolfgang Kastaun created an issue

Building a freshly downloaded ET, I get the following:

/kalahari/users/smeagol/ET/Lorentz/Cactus/configs/pull8try/build/SphericalHarmonicReconGen/ 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

Comments (10)

  1. Wolfgang Kastaun reporter

    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

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

  2. 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…

  3. 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.

  4. Wolfgang Kastaun reporter

    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.

  5. 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.

  6. 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.

  7. Log in to comment