Skip to content
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

Open
jml06 opened this issue Jun 28, 2024 · 24 comments
Open

Unable to build HDF5 with locally compiled szip or Zlib #4614

jml06 opened this issue Jun 28, 2024 · 24 comments
Assignees
Labels
Component - Documentation Doxygen, markdown, etc.

Comments

@jml06
Copy link

jml06 commented Jun 28, 2024

Dear developers,

Platform (please complete the following information)

  • HDF5 version : hdf5-1.14.4-3
  • OS and version: Centos-7.9.2009
  • Compiler and version: OneApi Intel 2024 or Gnu-11.2
  • Build system : cmake 3.29
  • MPI library and version : Intel/latest or OpenMPI-5.0.3 (compiled with gcc 11.2)

Context:

-bash-4.2$ more ./tools/BuildGnuLibs 
#!/usr/bin/env bash

ProjectDir=$1
echo "ProjectDir: "$ProjectDir

# --- OpenMPI-5.0.3 ---
if [ -d $ProjectDir/3rdParty/openmpi-5.0.3 ]; then
    rm -rf $ProjectDir/3rdParty/openmpi-5.0.3
fi

tar zxf $ProjectDir/3rdParty/openmpi-5.0.3.tar.gz -C $ProjectDir/3rdParty
cd $ProjectDir/3rdParty/openmpi-5.0.3

./configure --prefix=$ProjectDir/lib/Gnu/OpenMPI
make -j 36
make -j 36 install

printf "\n----------------------------------------------------------------------\n"
printf "   OpenMPI-5.0.3 Built and Installed"
printf "\n----------------------------------------------------------------------\n"

# --- ZLIB ---
if [ -d $ProjectDir/3rdParty/zlib-1.3.1 ]; then
    rm -rf $ProjectDir/3rdParty/zlib-1.3.1
fi

tar zxf $ProjectDir/3rdParty/zlib-1.3.1.tar.gz -C $ProjectDir/3rdParty
cd $ProjectDir/3rdParty/zlib-1.3.1

mkdir build
cd build
cmake .. -GNinja -DCMAKE_INSTALL_PREFIX=$ProjectDir/lib/Gnu/zlib  -DCMAKE_C_COMPILER="$MPI_C_Compiler"
ninja -j 36
ninja install

printf "\n----------------------------------------------------------------------\n"
printf "   ZLIB libraries Built and Installed"
printf "\n----------------------------------------------------------------------\n"

# --- SZIP---
if [ -d $ProjectDir/3rdParty/szip-2.1.1 ]; then
    rm -rf $ProjectDir/3rdParty/szip-2.1.1
fi

tar zxf $ProjectDir/3rdParty/szip-2.1.1.tar.gz -C $ProjectDir/3rdParty
cd $ProjectDir/3rdParty/szip-2.1.1

mkdir build
cd build
cmake .. -GNinja -DCMAKE_INSTALL_PREFIX=$ProjectDir/lib/Gnu/szip  -DCMAKE_C_COMPILER="$MPI_C_Compiler"
ninja -j 36
ninja install

printf "\n----------------------------------------------------------------------\n"
printf "   SZIP libraries Built and Installed"
printf "\n----------------------------------------------------------------------\n"

# --- HDF5 ---
if [ -d $ProjectDir/3rdParty/hdf5-1.14.4-3 ]; then
    rm -rf $ProjectDir/3rdParty/hdf5-1.14.4-3
fi

tar zxf $ProjectDir/3rdParty/hdf5-1.14.4-3.tar.gz -C $ProjectDir/3rdParty
cd $ProjectDir/3rdParty/hdf5-1.14.4-3

mkdir build
cd build
# Without Zlib or Szip compression this works !!! 
#cmake .. -GNinja -DCMAKE_INSTALL_PREFIX=$ProjectDir/lib/Gnu/hdf5 -DCMAKE_C_COMPILER="$MPI_C_Compiler" -DCMAKE_Fortran_COMPILER="$MPI_FC_Compiler" -DHDF5_ENABLE_PARALLEL=ON -DONLY_SHARED_LIBS=ON -DHDF5_BUILD_FORTRAN=ON -DBUILD_TESTING:BOOL
=OFF -DHDF5_BUILD_TOOLS:BOOL=OFF -DHDF5_ENABLE_Z_LIB_SUPPORT:BOOL=OFF -DHDF5_ENABLE_SZIP_SUPPORT:BOOL=OFF

# This gives : szip or zlib not found even with the reference to the cmake modules which exist in 
$ProjectDir/lib/Intel/szip/share/cmake:
-bash-4.2$ ls lib/Intel/szip/share/cmake/
szip-config.cmake  szip-config-version.cmake  szip-targets.cmake  szip-targets-noconfig.cmake

Same behavior if referencing Zlib previously compiled and installed.

VERBOSE=1 cmake .. -GNinja \
-DCMAKE_MODULE_PATH=$CMAKE_MODULE_PATH:$ProjectDir/lib/Intel/szip/share/cmake \
-DCMAKE_INSTALL_PREFIX=$ProjectDir/lib/Intel/hdf5 \
-DCMAKE_C_COMPILER="$MPI_C_Compiler" \
-DCMAKE_Fortran_COMPILER="$MPI_FC_Compiler" \
-DHDF5_ENABLE_PARALLEL=ON \
-DONLY_SHARED_LIBS=ON \
-DHDF5_BUILD_FORTRAN=ON \
-DBUILD_TESTING:BOOL=OFF \
-DHDF5_BUILD_TOOLS:BOOL=OFF \
-DHDF5_ENABLE_Z_LIB_SUPPORT:BOOL=OFF \
-DHDF5_ENABLE_SZIP_SUPPORT:BOOL=ON \
-DSZIP_DIR=$ProjectDir/lib/Intel/szip \
-DSZIP_LIBRARY:FILEPATH=$ProjectDir/lib/Intel/szip/lib/libszip-shared.so.2.1 \
-DSZIP_INCLUDE_DIR:PATH=$ProjectDir/lib/Intel/szip/include \
-DSZIP_USE_EXTERNAL:BOOL=NO


CMake Warning at CMakeFilters.cmake:127 (find_package):
  By not providing "FindSZIP.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "SZIP", but
  CMake did not find one.

  Could not find a package configuration file provided by "SZIP" with any of
  the following names:

    SZIPConfig.cmake
    szip-config.cmake

  Add the installation prefix of "SZIP" to CMAKE_PREFIX_PATH or set
  "SZIP_DIR" to a directory containing one of the above files.  If "SZIP"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  CMakeLists.txt:870 (include)


CMake Warning at CMakeFilters.cmake:158 (message):
  SZIP support in HDF5 was enabled but not found
Call Stack (most recent call first):
  CMakeLists.txt:870 (include)

Thanks in advance for your help, i really don't understand why i got this problem...

@byrnHDF byrnHDF self-assigned this Jun 28, 2024
@byrnHDF byrnHDF added the Component - Documentation Doxygen, markdown, etc. label Jun 28, 2024
@byrnHDF
Copy link
Contributor

byrnHDF commented Jul 15, 2024

HDF5 does not use zlib/szip shared libraries as it does not expose the APIs beyond the library.
However, by providing the include and lib directly it should happily accept those.
I know we have tested using pre-built libs before, Is the szip the libaec version? If so there are actually two libs that need to be specified.
Also if the szip was built with CMake and you have the szip-config files then you just need to specify the SZIP_ROOT variable to the install location and not the include/lib paths

@byrnHDF
Copy link
Contributor

byrnHDF commented Jul 16, 2024

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.

@byrnHDF
Copy link
Contributor

byrnHDF commented Aug 29, 2024

I believe we have addressed the issue in the latest dev code

@haampie
Copy link

haampie commented Sep 30, 2024

Hi @byrnHDF, it's not fixed:

find_package (ZLIB NAMES ${PACKAGE_NAME} COMPONENTS ${ZLIB_SEACH_TYPE})

Using COMPONENTS makes it such that CMake has to find a zlib package that defines those components. The builtin FindZLIB.cmake explicitly does not.

That only leaves zlib installs that come with CMake config files. But the default build system of zlib is their ./configure script, which does not generate a cmake config file.

So, you have to get rid of COMPONENTS, it is broken in the common case. You can choose to require CMake 3.24 instead, which has the following option in the FindZLIB.cmake module:

New in version 3.24: Set ZLIB_USE_STATIC_LIBS to ON to look for static libraries. Default is OFF.

@byrnHDF
Copy link
Contributor

byrnHDF commented Sep 30, 2024

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?

@haampie
Copy link

haampie commented Sep 30, 2024

ZLIB_ROOT doesn't work. By using two find_package's, you've changed the search order to first look for config files, then for non-config files. *_ROOT just adds a highest priority search path, it does not prevent searching CMAKE_PREFIX_PATH, system paths, etc.

When a zlib without config file is in CMAKE_PREFIX_PATH, clearly that should be used because the user says so. It is highly unexpected that it will pick up a system zlib instead just because it happens to have a cmake config file.

So, use find_package once and only once.

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.

ZLIB_USE_STATIC_LIBS on the other hand...

@vessokolev
Copy link

vessokolev commented Dec 12, 2024

HDF5 does not use zlib/szip shared libraries as it does not expose the APIs beyond the library. However, by providing the include and lib directly it should happily accept those. I know we have tested using pre-built libs before, Is the szip the libaec version? If so there are actually two libs that need to be specified. Also if the szip was built with CMake and you have the szip-config files then you just need to specify the SZIP_ROOT variable to the install location and not the include/lib paths

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:

 2. If you plan to use Zlib or Szip:
     A. Download the binary packages and install them in a central location.
        For example on Windows, create a folder extlibs and install the
        packages there. Add the following CMake options:
           -DH5_ZLIB_LIBRARY:FILEPATH=some_location/lib/zlib.lib
           -DH5_ZLIB_INCLUDE_DIR:PATH=some_location/include
           -DZLIB_USE_EXTERNAL:BOOL=OFF
           -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{ZLIB_ROOT} "some_location")
           set(ENV{SZIP_ROOT} "some_location")

Following those recommendations just produces the outcome the others have already reported:


CMake Warning:
  Manually-specified variables were not used by the project:

    H5_SZIP_INCLUDE_DIR
    H5_SZIP_LIBRARY
    H5_ZLIB_INCLUDE_DIR
    H5_ZLIB_LIBRARY

To compare, I placed below that particular CMake invocation that successfully adds ZLIB and SZIP support (via Libaec) to HDF5 1.14.0:

cmake -B build-${COMPILER}-${VARIANT} \
      -DCMAKE_C_COMPILER=icc \
      -DCMAKE_CXX_COMPILER=icpc \
      -DCMAKE_Fortran_COMPILER=ifort \
      -DCMAKE_VERBOSE_MAKEFILE=OFF \
      -DBUILD_TESTING=OFF \
      -DCMAKE_C_FLAGS="${internal_COMPILER_C_FLAGS}" \
      -DCMAKE_CXX_FLAGS="${internal_COMPILER_CXX_FLAGS}" \
      -DCMAKE_Fortran_FLAGS="${internal_COMPILER_Fortran_FLAGS}" \
      -DHDF5_ENABLE_PARALLEL=OFF \
      -DLARGE_PARALLEL_IO=OFF \
      -DHDF5_BUILD_FORTRAN=ON \
      -DHDF5_ENABLE_SZIP_SUPPORT=ON \
      -DHDF5_ENABLE_SZIP_ENCODING=ON \
      -DUSE_LIBAEC=ON \
      -Dlibaec_LIBRARY=/opt/software/${LIBAEC_MODULE_NAME}/${LIBAEC_MAJOR_VERSION}/${LIBAEC_VERSION}-${COMPILER}/lib64/libsz.so \
      -Dlibaec_INCLUDE_DIR=/opt/software/${LIBAEC_MODULE_NAME}/${LIBAEC_MAJOR_VERSION}/${LIBAEC_VERSION}-${COMPILER}/incude \
      -DHDF5_ENABLE_Z_LIB_SUPPORT=ON \
      -DZLIB_INCLUDE_DIR=/opt/software/${ZLIB_MODULE_NAME}/${ZLIB_MAJOR_VERSION}/${ZLIB_VERSION}-${COMPILER}/include \
      -DZLIB_LIBRARY_RELEASE=/opt/software/${ZLIB_MODULE_NAME}/${ZLIB_MAJOR_VERSION}/${ZLIB_VERSION}-${COMPILER}/lib/libz.so \
      -DSZIP_LIBRARY=/opt/software/${LIBAEC_MODULE_NAME}/${LIBAEC_MAJOR_VERSION}/${LIBAEC_VERSION}-${COMPILER}/lib64/libsz.so \
      -DSZIP_INCLUDE_DIR=/opt/software/${LIBAEC_MODULE_NAME}/${LIBAEC_MAJOR_VERSION}/${LIBAEC_VERSION}-${COMPILER}/include \
      -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}-${COMPILER}-${VARIANT}

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

H5_SZIP_INCLUDE_DIR
H5_SZIP_LIBRARY
H5_ZLIB_INCLUDE_DIR
H5_ZLIB_LIBRARY

Need to remove the "H5_" prefix - development documentation will be updated with #5085

@vessokolev
Copy link

vessokolev commented Dec 12, 2024

H5_SZIP_INCLUDE_DIR
H5_SZIP_LIBRARY
H5_ZLIB_INCLUDE_DIR
H5_ZLIB_LIBRARY

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:

release_docs/INSTALL_CMake.txt

It incudes the following statement:

      RECOMMENDED:
        Users can perform the configuration step without using the visual
        cmake-gui program. We use the file cacheinit.cmake in the
        config/cmake source folder for our testing. This file enables all of the
        basic options and we turn specific options on or off for testing
        using the following command line within the build directory:

...

            ########################
            # compression options
            ########################
            set (ZLIB_PACKAGE_NAME "zlib" CACHE STRING "Name of ZLIB package" FORCE)
            set (ZLIB_TGZ_NAME "zlib-1.3.tar.gz" CACHE STRING "Use HDF5_ZLib from compressed file" FORCE)
            set (ZLIB_TGZ_ORIGPATH "https://github.com/madler/zlib/releases/download/v1.3" CACHE STRING "Use ZLIB from original location" FORCE)
            set (ZLIB_USE_LOCALCONTENT ON CACHE BOOL "Use local file for ZLIB FetchContent" FORCE)
            set (ZLIB_GIT_URL "https://github.com/madler/zlib.git" CACHE STRING "Use ZLIB from  GitHub repository" FORCE)
            set (ZLIB_GIT_BRANCH "develop" CACHE STRING "" FORCE)
            set (HDF5_USE_ZLIB_NG OFF CACHE BOOL "Use zlib-ng library as zlib library" FORCE)
            set (ZLIBNG_PACKAGE_NAME "zlib-ng" CACHE STRING "Name of ZLIBNG package" FORCE)
            set (ZLIBNG_TGZ_NAME "2.1.6.tar.gz" CACHE STRING "Use HDF5_ZLib from compressed file" FORCE)
            set (ZLIBNG_TGZ_ORIGPATH "https://github.com/zlib-ng/zlib-ng/archive/refs/tags" CACHE STRING "Use ZLIBNG from original location" FORCE)
            set (ZLIBNG_GIT_URL "https://github.com/zlib-ng/zlib-ng.git" CACHE STRING "Use ZLIBNG from  GitHub repository" FORCE)
            set (ZLIBNG_GIT_BRANCH "develop" CACHE STRING "" FORCE)
            set (LIBAEC_PACKAGE_NAME "libaec" CACHE STRING "Name of AEC SZIP package" FORCE)
            set (LIBAEC_TGZ_NAME "libaec-1.1.3.tar.gz" CACHE STRING "Use SZip AEC from compressed file" FORCE)
            set (LIBAEC_TGZ_ORIGPATH "https://github.com/MathisRosenhauer/libaec/releases/download/v1.1.3" CACHE STRING "Use LIBAEC from original location" FORCE)
            set (LIBAEC_USE_LOCALCONTENT ON CACHE BOOL "Use local file for LIBAEC FetchContent" FORCE)
            set (LIBAEC_GIT_URL "https://github.com/MathisRosenhauer/libaec.git" CACHE STRING "Use LIBAEC from  GitHub repository" FORCE)
            set (LIBAEC_GIT_BRANCH "v1.1.3" CACHE STRING "" FORCE)

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 libaec-config.cmake, provided by an external Libaec library installation, or should we try to solve the issue ourselves? The current configuration of the CMake code included in the HDF5 project (through SZIP_DIR) is configured to look for szip-config.cmake, which is not provided by the external Libaec installations.

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

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.

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

The (*_DIR) variable is not correct as CMake recommends the *_ROOT variable be used.

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

Have you tried setting the LIBAEC_ROOT or SZIP_ROOT ENV var to the root install of the libeac install?

@vessokolev
Copy link

The (*_DIR) variable is not correct as CMake recommends the *_ROOT variable be used.

      -Dlibaec_ROOT=/opt/software/libaec/1/1.1.3-llvm \

CMake Warning:
  Manually-specified variables were not used by the project:

    libaec_ROOT

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

Also needs to be all CAPS.

@vessokolev
Copy link

vessokolev commented Dec 12, 2024

Also needs to be all CAPS.

From release_docs/HISTORY-1_14.txt, quote:

Use libaec_DIR or libaec_ROOT

All caps do not work either:

CMake Warning:
  Manually-specified variables were not used by the project:

    LIBAEC_ROOT

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

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.

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

IF that doesn't work then we might need to rename the find_package variables.

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

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.

@vessokolev
Copy link

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.

As I explained before, that does not work. First, the related configuration for finding the SZIP packages looks for szip-config.cmake. That file is not provided by Libaec. Libaec provides libaec-config.cmake, which cannot be parsed by find_package SZIP, for it contains very different declarations set than the expected one.

Setting SZIP_ROOT as recommended:

cmake -B build-${COMPILER}-${VARIANT} \
      -DCMAKE_C_COMPILER=icc \
      -DCMAKE_CXX_COMPILER=icpc \
      -DCMAKE_Fortran_COMPILER=ifort \
      -DCMAKE_VERBOSE_MAKEFILE=OFF \
      -DBUILD_TESTING=OFF \
      -DCMAKE_C_FLAGS="${internal_COMPILER_C_FLAGS}" \
      -DCMAKE_CXX_FLAGS="${internal_COMPILER_CXX_FLAGS}" \
      -DCMAKE_Fortran_FLAGS="${internal_COMPILER_Fortran_FLAGS}" \
      -DHDF5_ENABLE_PARALLEL=OFF \
      -DLARGE_PARALLEL_IO=OFF \
      -DHDF5_BUILD_FORTRAN=ON \
      -DSZIP_ROOT=/opt/software/libaec/1/1.1.3-llvm/cmake \
      -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}-${COMPILER}-${VARIANT}

does not successfully activate any alternative checks. The folder /opt/software/libaec/1/1.1.3-llvm/cmake contains the necessary files:

libaec-config-version.cmake
libaec-config.cmake

In fact, the find_package SZIP insists on parsing the szip-config.cmake located under SZIP_DIR and cannot find it (for it does not exist there):

-- Could NOT find SZIP (missing: SZIP_DIR)
CMake Warning at CMakeFilters.cmake:157 (find_package):
  By not providing "FindSZIP.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "SZIP", but
  CMake did not find one.

  Could not find a package configuration file provided by "SZIP" with any of
  the following names:

    SZIPConfig.cmake
    szip-config.cmake

  Add the installation prefix of "SZIP" to CMAKE_PREFIX_PATH or set
  "SZIP_DIR" to a directory containing one of the above files.  If "SZIP"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  CMakeLists.txt:909 (include)


CMake Warning at CMakeFilters.cmake:188 (message):
  SZIP support in HDF5 was enabled but not found
Call Stack (most recent call first):
  CMakeLists.txt:909 (include)

So far, I see no working method for locating and examining libaec-config.cmake in 1.14.5. I am continuing checking the CMake code included there.

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

Can you try one more thing - 1.14. needs the LIBAEC_PACKAGE_NAME set to libaec, so
-DLIBAEC_PACKAGE_NAME=libaec
-DSZIP_ROOT=/opt/software/libaec/1/1.1.3-llvm/cmake
-DLIBAEC_ROOT=/opt/software/libaec/1/1.1.3-llvm/cmake
-DHDF5_ENABLE_SZIP_SUPPORT=ON

@vessokolev
Copy link

vessokolev commented Dec 12, 2024

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 /opt/software/libaec/1/1.1.3-llvm/cmake/libaec-config.cmake becomes examined, but afterwards CMake says is cannot find neither libaecConfig.cmake nor libaec-config.cmake, which is a kind of contradiction:


CMake Warning (dev) at /opt/software/cmake/3/3.31.1/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:441 (message):
  The package name passed to `find_package_handle_standard_args` (libaec)
  does not match the name of the calling package (SZIP).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /opt/software/libaec/1/1.1.3-llvm/cmake/libaec-config.cmake:50 (find_package_handle_standard_args)
  CMakeFilters.cmake:155 (find_package)
  CMakeLists.txt:909 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Could NOT find libaec: found neither libaecConfig.cmake nor libaec-config.cmake
...


CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
SZIP_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /project/soft-raid1-admin/build/vkolev/compile/hdf5-hdf5_1.14.5/src
   used as include directory in directory /project/soft-raid1-admin/build/vkolev/compile/hdf5-hdf5_1.14.5/src

CMake Error in src/CMakeLists.txt:
  Found relative path while evaluating include directories of "hdf5-static":

    "SZIP_INCLUDE_DIR-NOTFOUND"



CMake Error in src/CMakeLists.txt:
  Found relative path while evaluating include directories of "hdf5-shared":

    "SZIP_INCLUDE_DIR-NOTFOUND"



-- Generating done (2.6s)
CMake Warning:
  Manually-specified variables were not used by the project:

    LIBAEC_ROOT


On the other side, the file /opt/software/libaec/1/1.1.3-llvm/cmake/libaec-config.cmake contains at line 50 the following statement:


find_package_handle_standard_args(libaec
  FOUND_VAR libaec_FOUND
  REQUIRED_VARS libaec_LIBRARY libaec_INCLUDE_DIR SZIP_LIBRARY SZIP_INCLUDE_DIR
  VERSION_VAR libaec_VERSION
  CONFIG_MODE
)

Even if I promptly provide the required vars (needed by that statement):

      -Dlibaec_LIBRARY=/opt/software/libaec/1/1.1.3-llvm/lib64/libaec.so \
      -Dlibaec_INCLUDE_DIR=/opt/software/libaec/1/1.1.3-llvm/include \
      -DSZIP_LIBRARY=/opt/software/libaec/1/1.1.3-llvm/lib64/libsz.so \
      -DSZIP_INCLUDE_DIR=/opt/software/libaec/1/1.1.3-llvm/include \

the problem still persists:

CMake Warning (dev) at /opt/software/cmake/3/3.31.1/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:441 (message):
  The package name passed to `find_package_handle_standard_args` (libaec)
  does not match the name of the calling package (SZIP).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /opt/software/libaec/1/1.1.3-llvm/cmake/libaec-config.cmake:50 (find_package_handle_standard_args)
  CMakeFilters.cmake:155 (find_package)
  CMakeLists.txt:909 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Could NOT find libaec: found neither libaecConfig.cmake nor libaec-config.cmake (found version "1.1.3")

...

CMake Warning:
  Manually-specified variables were not used by the project:

    LIBAEC_ROOT

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 12, 2024

Thanks for trying - I will investigate this next week and implement a CI that will keep us from messing this up in the future.

@vessokolev
Copy link

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!

@byrnHDF
Copy link
Contributor

byrnHDF commented Dec 20, 2024

See #5182 for what should fix the problems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component - Documentation Doxygen, markdown, etc.
Projects
None yet
Development

No branches or pull requests

4 participants