Here’s one workaround solution that may work for you:
export CC=$MPICC
export FC=$MPIFC
export CXX=$MPICXX
export F90=$MPIF90
export F77=$MPIF77
pip install cmake # This will install recent cmake that works for HDF5.
export PATH=/home/u177454/.local/lib/python3.9/site-packages/cmake/data/bin:$PATH
cmake -D HDF5_BUILD_FORTRAN:BOOL=ON ..
The above worked until it had some issue with linking compression library. It did not complain during configuration, at least.
[ 24%] Linking C shared library ../bin/libnull_vol_connector.so
[ 24%] Built target null_vol_connector
[ 24%] Building C object test/CMakeFiles/cache.dir/cache.c.o
[ 24%] Linking C executable ../bin/cache
../bin/libhdf5.so.303.0.0: undefined reference to `compress2'
../bin/libhdf5.so.303.0.0: undefined reference to `inflate'
../bin/libhdf5.so.303.0.0: undefined reference to `inflateInit_'
Another possibility is to use
spack install hdf5+fortran%oneapi@2022.2.1
, which I’m currently testing now.
Please consider donation if you like our fast response.
The config.log posted above suggests this bug is in play:
Note the solution in the very last message in that thread (2020 Dec. 8). Now, configure here was built by autoconf 2.69 and included as part of the HDF5 1.13.2 source release. The best solution is to update to autoconf 2.70 or later, before constructing the next release.
The HDF5 team could also release a rebuilt configure to apply to 1.13.2, or users could be instructed on how to run autoconf and fix configure for themselves.
[Edit: corrected typo in autoconf version number above.]
We probably won’t update the configure file in released 1.13.x versions since those are basically glorified release candidates for 1.14.0.
I’m hesitant to bump the Autoconf version to 2.70 since it was just released in late 2020 (2.69 is circa 2012). A lot of the systems we support are fairly conservative about updating, so that might result in more headaches than a bug in a beta version of HPC Toolkit.
For now, if reconfiguring w/ Autoconf 2.70 is an acceptable work-around, just run autogen.sh in the source root to rebuild the Autotools files and go from there (or use CMake). On our end, we’ll look into generating the Autotools files for 1.14.0 w/ Autoconf 2.70+ and bumping the Autoconf version. I’m actually thinking about removing Autotools support entirely after 1.14.0 is released, so this may be a non-issue in the future (there will be a blog post about this next week).
As for OneAPI, I’d be thrilled to have better support for that in HDF5 if we’re currently deficient. Please create issues in GitHub (or, even better, send us PRs for fixes!) for anything that fails or could be improved and we’ll do our best to address them.
As you mentioned some of your systems are fairly conservative in updating systems. So many system admins may not be versed in cmake as it acts like a completely different language.
If you do go the route of switching to cmake only you will probably need an in depth setup instructions for first time users.
Personally I hate anything that uses cmake because it feels like a glorified skin over ./configure scripts.
I understand your concern and felt the same way, too!
I like the OpenBSD way of having one Makefile and just run make.
The biggest problem of CMake is that it has too many dependencies.
By the way, I was happy to see GrADS being used in the attached build script.
I’m also curious how GrADS will compile and work under Intel oneAPI.
Please let me know how the GrADS installation goes.
I want to update http://hdfeos.org/software/grads.php page accordingly.
What is “paywall”?
I haven’t used both opengrads and grads for a while.
I just want to learn from you whether they can be built successfully or not with oneAPI + latest HDF5/netCDF/GRIB/etc.
@derobins, in this context, Autoconf is used only as a developer-side tool to auto-generate the release version of the configure file. My understanding is that no downstream dependency on a specific Autoconf version is created. When the released configure file is sufficient, users should never need to run Autoconf for any routine reason, or have a specific version installed on their side.
Therefore I think you are safe to use a newer Autoconf version for constructing releases, with no downstream consequences. If I have missed something, please let us know.
@dave.allured - Yes, that is correct. We can bump the Autoconf version for generating configure in our release branches, no problem. What I am hesitant about is bumping AC_PREREQ in configure.ac as many people on older systems build the HDF5 develop branch from source. We don’t commit Autotools generated files until we create a release branch, so those people would, in fact, have to run Autoconf.