[petsc-dev] Building MED on cross-compile systems where HDF5 is provided by module

[Faibussowitsch, Jacob]

Having recently built petsc on Cori with MED I want to share my configure arguments. I don’t know how much this has to do with petsc configure or MED configure, but that being said, this is required to build MED on systems with cross compile.

Tl;dr:
--with-hdf5-dir=$HDF5_ROOT --download-med --download-med-cmake-arguments="-DHDF5_INCLUDE_DIRS=$PE_HDF5_DIR/include -DHDF5_VERSION=$CRAY_HDF5_VERSION -DHDF5_LIBRARIES=-L$HDF5_ROOT/lib/libhdf5”

Successfully configure.log below.

HDF5 cannot be built using —download-hdf5 on systems where —with-batch=1 is required, and where your compilers are not —with-cc=cc, —with-cxx=CC —with-fc=ftn (i.e. cray cross compilers). This means you must load the appropriate HDF5 module, and provide —with-hdf5. When building MED with cmake however, you immediately run into issues.

0. Initially MED configure looks for a hdf5 install and a hdf5-configure.cmake, which it won’t find with an installed module. In fact, it doesn’t find the hdf5 install AT ALL. You MUST point meds cmake configure to the include directory of the hdf5 install directory.
1. From this point, it assumes the HDF5_ROOT directory to be the directory immediately one level up from the include dir.
2. Next it looks for the HDF5 version number, which it assumes to be somewhere in the Path of the include directory. And this was the case on Cori, but for whatever reason, it never parsed this correctly. E.g. $HDF5_ROOT was /opt/cray/pe/hdf5/1.10.2.0/INTEL/16.0, where 1.10.2.0 is clearly the version number, but the MED configure output was:

-- HDF5: Using hdf5 compiler wrapper for all C compiling
-- Found HDF5 version [NOTE, HERE IT IS PRINTING WHAT IT FINDS AS THE VERSION, I.E. NOTHING] -- parallel flag is set to [ALSO NOTHING]
-- Cannot find HDF5_VERSION - maybe cmake is too old [NO IT ISN’T, CMAKE_VERSION=3.14.4]
-- _versionComponents=
-- HDF5_VERSION=
CMake Error at config/cmake_files/FindMedfileHDF5.cmake:178 (LIST):
  LIST GET given empty list
Call Stack (most recent call first):
  config/cmake_files/medMacros.cmake:396 (FIND_PACKAGE)
  CMakeLists.txt:101 (MED_FIND_HDF5)

CMake Error at config/cmake_files/FindMedfileHDF5.cmake:179 (LIST):
  LIST GET given empty list
Call Stack (most recent call first):
  config/cmake_files/medMacros.cmake:396 (FIND_PACKAGE)
  CMakeLists.txt:101 (MED_FIND_HDF5)

CMake Error at config/cmake_files/FindMedfileHDF5.cmake:180 (LIST):
  LIST GET given empty list
Call Stack (most recent call first):
  config/cmake_files/medMacros.cmake:396 (FIND_PACKAGE)
  CMakeLists.txt:101 (MED_FIND_HDF5)

CMake Error at config/cmake_files/medMacros.cmake:402 (MESSAGE):
  HDF5 version is .  Only versions >= 1.10.2 are supported.
Call Stack (most recent call first):
  CMakeLists.txt:101 (MED_FIND_HDF5)

Here the errors are in parsing a cmake LIST supposedly contains the version number, but that list is empty (??). Except it’s not, since there is an if statement specifically checking if the LIST item is populated, which passes (??????????????????????????). In order for this check to pass you MUST pass -DHDF5_VERSION=$CRAY_HDF5_VERSION, which I guess force populates the internal cmake HDF5_VERSION variable.

3. Finally, even though MED now explicitly has $HDF5_ROOT, $HDF5_INCLUDE it is inexplicably unable to find $HDF5_ROOT/lib, and so you must directly supply it with the path to the libhdf5 file with -DHDF5_LIBRARIES=-L$HDF5_ROOT/lib/libhdf5”.

Additional comments:
It is possible to “build” MED a different way, by instead of passing $PE_HDF5_DIR = /opt/cray/pe/hdf5/1.10.2.0, you pass $HDF5_ROOT = /opt/cray/pe/hdf5/1.10.2.0/INTEL/16.0, which completes the configure stage but fails during make in the linking stage. Ld attempts to find and link hdf5::hdf5-shared/static, which look like they are cmake build targets, not lib files. This is somewhat corroborated by this forum post complaining about a similar problem with netcdf https://bugs.archlinux.org/task/60345.

Best,

Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20191121/c49dd3c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.log
Type: application/octet-stream
Size: 2887843 bytes
Desc: configure.log
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20191121/c49dd3c2/attachment-0001.obj>