-
-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to build HDF5 with locally compiled szip or Zlib #4614
Comments
HDF5 does not use zlib/szip shared libraries as it does not expose the APIs beyond the library. |
We believe we have located the actual problem - is has to do with the expected vs actual usage of the CMake FindZLIB.cmake module. We will have a fix for the current development branch soon. |
I believe we have addressed the issue in the latest dev code |
Hi @byrnHDF, it's not fixed: Line 95 in d507b7c
Using That only leaves zlib installs that come with CMake config files. But the default build system of zlib is their So, you have to get rid of
|
Line 95 is used to find a cmake build - line 100 was intended to find other types. Have you tried specifying the ZLIB_ROOT so it doesn't go looking in other places? |
When a zlib without config file is in So, use Apart from that, I don't think you should expect a cmake config file at all: (a) the promoted build system by zlib's readme is their configure script, and (b) even their cmake build systems seems to have issues w.r.t. config files. It's not universal and will not be for a long time.
|
Nowadays, almost no one uses the old SZIP code any more due to its licence. For instance, most HPC centres compile HDF5 code against Libaec, avoiding that way the old SZIP code. Unfortunately, the CMake discovery method that was supposed to detect Libaec in HDF5 1.14.5 is broken too and cannot find the Libaec installation, even if the folder containing the libaec-config.cmake file is part of the CMAKE_MODULE_PATH catalogue. The same applies to 1.14.3 and 1.14.4. This part of the documentation (located inside the release_docs/INSTALL_CMake.txt file) does not solve the problem either:
Following those recommendations just produces the outcome the others have already reported:
To compare, I placed below that particular CMake invocation that successfully adds ZLIB and SZIP support (via Libaec) to HDF5 1.14.0:
|
Need to remove the "H5_" prefix - development documentation will be updated with #5085 |
Thanks for the prompt reply, but removing the prefix does not contribute in any way to the solution of the problem. Sadly, the general problem with discovering the Libaec external installations remains, and it is definitely a CMake problem. I got this content gone over:
It incudes the following statement:
Although I comprehend and appreciate the explicit approach taken by the CMake developers to retrieve/fetch the code of the compressors every time they need to test HDF5 code, it is important to note that this method of code compilation contravenes the code sanitation guidelines enforced in large compute farms. Libaec must be compiled separately, passed quality assurance, and approved for linking to other libraries or applications. In other words, the recommended approach for retrieving the compressor libraries as a code every time we need to construct the HDF5 code is unsuitable and may create problems in specific environments. My question is simple. Are there any plans to fix the CMake code to detect the presence of |
We intend that the compression libs can be used from multiple options - find_package call to an install, built from source from either a tgz file or GH repo. The cacheinit.cmake file is something provided as a convenience and which we use for testing - it is not a recommendation, just a use case example. |
The (*_DIR) variable is not correct as CMake recommends the *_ROOT variable be used. |
Have you tried setting the LIBAEC_ROOT or SZIP_ROOT ENV var to the root install of the libeac install? |
|
Also needs to be all CAPS. |
From
All caps do not work either:
|
Whoops - that old note is definitely wrong - will check the current docs for issues. Since we do a find_package SZIP in the code try setting SZIP_ROOT. |
IF that doesn't work then we might need to rename the find_package variables. |
Last week, we have discussed creating a CI workflow to test this use case - the problem is getting things installed and correctly finding those installs. So we are working on this. |
As I explained before, that does not work. First, the related configuration for finding the SZIP packages looks for Setting
does not successfully activate any alternative checks. The folder
In fact, the find_package SZIP insists on parsing the
So far, I see no working method for locating and examining |
Can you try one more thing - 1.14. needs the LIBAEC_PACKAGE_NAME set to libaec, so |
The problems is that we are looking for SZIP package, while the SZIP provider is Libaec. Anyway, the result of the test you suggested is shown below and it is a mess. The file
On the other side, the file
Even if I promptly provide the required vars (needed by that statement):
the problem still persists:
|
Thanks for trying - I will investigate this next week and implement a CI that will keep us from messing this up in the future. |
Thank you very much in advance for the efforts! |
See #5182 for what should fix the problems |
Dear developers,
Platform (please complete the following information)
Context:
Same behavior if referencing Zlib previously compiled and installed.
Thanks in advance for your help, i really don't understand why i got this problem...
The text was updated successfully, but these errors were encountered: