Normally I would configure and make HDF5 with “./configure --prefix=my/path --enable-fortran --with-szlib=/path/to/szlib/directory” after having set the FC=ifort environment variable.
What would be the corresponding CMake configuration in 1.14.4-2? None of the obvious “-DSZLIB…” seem to have any effect, the build system still complains that it can’t find szlib.
Context is that the “configure” script in 1.14.4-2 produces non-functional code with Intel ifort, and I’m hoping that the CMake build system might produce working code. The “configure” script from 1.12.3 works fine with ifort, and 1.14.4-2 is known compatible with the linking code as it works correctly with gfortran.
There are multiple ways to find szip/zlib with CMake and the simplest is if the library is in the search path for CMake. See the cmake documentation for more.
Likely you want the following from our release_docs/INSTALL_CMake.txt - section IV Item 2:
-DH5_SZIP_LIBRARY:FILEPATH=some_location/lib/szlib.lib
-DH5_SZIP_INCLUDE_DIR:PATH=some_location/include
-DSZIP_USE_EXTERNAL:BOOL=OFF
where “some_location” is the full path to the extlibs folder.
Also the appropriate environment variable must be set;
set(ENV{SZIP_ROOT} “some_location”)
In the archive that I downloaded (“hdf5-1.14.4-2.tar.gz”) the CMake options listed in that document are “DSZIP_LIBRARY” and similar (i.e., no “H5” prefix).
Unfortunately both that variable and the “H5_SZIP_LIBRARY” variable result in “Manually-specified variables were not used by the project” warnings from CMake, and do not enable szip to be found. I’m also not seeing an obvious analogs using “cmake -LA”, though might be missing something.
For 1.14.4-2 release you’ll want to use the names from that source ball’s INSTALL_CMake.txt file.
Also note that the name “SZIP_LIBRARY” is appended to the CMake define indicator “-D”
Unfortunately the variables listed in the “INSTALL_CMake.txt” file are not valid (using “-D” from the command line). Unless the CMakeLists.txt file in the root directory is supposed to be modified/replaced, or the archive available for download from HDF5 Library and Tools 1.14.4 | The HDF Group is not the correct thing to be getting, I’m still very much at a loss.
I believe that link is the source from github.
What version of CMake are you using, CMake 3.25+ will allow use of CMakePresets which is nice because we could create a UserPresets file just for your needs.
Compression filters do have a number of options for flexibility, however I prefer to build them in-line everywhere. Even then there are options depending on if you want to download them from the source repos or use a local tgz file.
As indicated in INSTALL_CMake.txt, and used in the config/cmake/cacheinit.cmake file and also in the CMakePresets.json file, the basic settings for using the filters from a local folder are:
-DHDF5_ALLOW_EXTERNAL_SUPPORT:STRING=TGZ/GIT # if building the filters in-line
-DTGZPATH:PATH=
-DHDF5_ENABLE_SZIP_SUPPORT:BOOL=ON
-DHDF5_ENABLE_SZIP_ENCODING:BOOL=ON
-DLIBAEC_TGZ_NAME:STRING=libaec-1.0.6.tar.gz or libaec-v1.1.3.tar.gz #match the filename to your version
-DLIBAEC_USE_LOCALCONTENT:BOOL=ON #required to build in-line otherwise will search for the filter on the machine. Searching requires more options for providing hints to the search.
If you have CMake 3.25+ then you might want to just try using presets from the source folder:
cmake --workflow --preset ci-StdShar-GNUC --fresh
this will create a build folder in the parent dir and auto download the filters.
The configuration gets further, but fails because:
CMake Error at config/cmake/HDFLibMacros.cmake:36 (add_library):
add_library cannot create ALIAS target “zlib-static” because another target
with the same name already exists.
Call Stack (most recent call first):
CMakeFilters.cmake:85 (EXTERNAL_ZLIB_LIBRARY)
CMakeLists.txt:870 (include)
and because:
CMake Error at config/cmake/HDFLibMacros.cmake:71 (add_library):
add_library cannot create ALIAS target “szaec-static” because another
target with the same name already exists.
Call Stack (most recent call first):
CMakeFilters.cmake:137 (EXTERNAL_SZIP_LIBRARY)
CMakeLists.txt:870 (include)
Looking at the output of CMAKE -LA, both “ZLIB_USE_EXTERNAL:BOOL=ON” and “ZLIB_USE_LOCALCONTENT:BOOL=ON” appear to be set. Adding to the command line to turn off external:
Has no effect. Both errors still occur and the variables are both “ON” after the configuration step fails. I’m using CMake 3.29.3, but do not have the ability to use any auto download features on the machine in question.
You did clear out your build folder between runs, yes? Because CMake will skip steps and make assumptions that certain things are already configured.
I use the same process locally for all my hdf5 development, so it should be a matter of config/options.
If you can’t download and you are using tgz files - make sure the files are in the same folder as TGZPATH indicates. Another option is to use --log-level=VERBOSE on the command line for configure.
Yes, I completely delete the build subdirectory before each configure just to be safe.
I re-downloaded all sources, including HDF5 (hdf5-1.14.4-2.tar.gz) and re-ran on a completely different machine. Same thing, so I’m not sure why it isn’t reproducible. My testing directory structure has a build directory “/home/username/hdf5/hdf5-1.14.4-2/build” and a sources directory (containing libaec-v1.1.3.tar.gz and zlib-1.3.1.tar.gz) “/home/username/hdf5/sources”. I then run the command:
You might want to double check your paths; if “-DTGZPATH:STRING=”/directory_that_does_not_exist" the configuration will silently ignore it (at the default logging level).
Also on that cmake line add -VV and --log-level=VERBOSE to the options. That should show all the messages. Because there are more info including filters and paths.
Increasing the logging level shows nothing, other than it does find the *.gz files before erroring out.
The CMake system also seems to be incapable of building the fortran_hl libraries (cmake find_package used by other codes will error out) despite the “build_hl_lib” Boolean being on, so at this point I’m going to cut my losses and go back to the old configure system. Appreciate the help, but it looks like the current CMake build system is simply non-functional for my purposes.
