All tests passed but oneAPI generates 3000 warnings.
Unfortunately, I had to use the latest Intel compiler 2025.0 to verify my patch.
Please let me know if my HDF5 fork works on your system with your older oneAPI compiler.
Thank you so much again for the detailed error reports and trying so many different options! Your thoroughness helped me a lot to patch my HDF5 fork.
We have an older version install that we’ve been using with autotools HDF5 configure builds for several years. The configure option there is --with-szlib=path to libaec directory where the directory contains bin include lib and share directories for libaec. That install still works for HDF5 develop before autotools was removed. I tried installing libaec v1.1.3 with cmake, and that was not successfully configured with the same HDF5 code. I also tried to build libaec v1.1.3 with autotools, but the autogen.sh in the libaec code needs gnulib-tool which the machine doesn’t have. I’ll try tomorrow on some other platforms.
Today I found why hdf5 configure --with-szlib=<libaec install directory> worked for an older libaec version install, but not for the latest release libaec v1.1.3. The older version installed libaec and libsz libs in the lib directory. The latest version installs in the lib64 directory, and hdf5 configure looks only in lib. Searching the configure file for ‘szlib_lib="$withval/lib’ and adding 64 to lib enabled szip with the libaec v1.1.3 install.
Configuring with CMake 3.26.3 also enabled hdf5 (develop) with szip using this configure command: “cmake -DHDF5_ENABLE_SZIP_SUPPORT=ON -Dlibaec_ROOT=/mnt/hdf/packages/libaec_v1.1.3/Linux3.10-x86_64-gcc …/hdf5” where /mnt/hdf/packages/libaec_v1.1.3/Linux3.10-x86_64-gcc was the installed libaec v1.1.3 and hdf5 was the hdf5 source directory. The libaec v1.1.3 install includes cmake/libaec-config.cmake, which allows cmake to find it with the -Dlibaec_ROOT setting. The older version didn’t. I suspect when the libaec-config.cmake file is missing, CMake may not add szip.
specific answer to the question how to point configure to libaec instead of szip (since configure reported that it could not find libaec when I just drop-in replaced the root dir for the libaec instance against the szip flag). With the latest libaec, and possibly some but not all earlier versions, the lib directory is now lib64, but HDF5 configure is still looking for the libs in a ‘lib’ directory. Changing ‘szlib_lib=“$withval/lib’ to ‘szlib_lib=”$withval/lib64’ in the configure file found libaec with the --with-szlib= option for me.
@hyoklee Thank you so much for this - I’ll try it out next time I’m at my machine. Are there any advantages to using cmake at this point if I already got it compiled with regular make?
@lrknox So you are saying to point to the root dir for libaec using the --with-szlib flag but make sure that I point to lib64 in that root dir using the --szlib_lib flag?
I don’t see any advantage.
However, your app will not work with hdf5-2.0.0 and above in the future:
Warning
Heads Up: HDF5 Drops Autotools March 10th
The day has arrived: the day we've all been dreading—or eagerly anticipating, depending on your perspective. Yes, we're switching to CMake-only builds in HDF5. Prepare yourselves.
The PR stripping all autotools will go into the "develop" branch on March 10, 2025. HDF5 2.0, scheduled for release in Fall 2025, will only support the CMake build system.
If you’d like to learn more about this decision, check out this blog post from November 2022: Can we remove the autotools? And the HDF5 2.0 planning wiki. If you use autotools for your builds, now is a great time to update your workflows to CMake.
