Co-existing HDF5 (serial and parallel) + PKG_CHECK_MODULES issue about trexio

[q-posev]

Thanks @v1j4y !

This bug was observed on the local curie cluster at LCPQ. Both issues have the same origin, which I will address as No.2 in the list below. However, on curie there are two unrelated bugs:

1. Issue with co-existing HDF5 installations (serial and parallel):

• Bug: Several modules (e.g. HDF5) are installed using Spack package manager on curie. These modules can be loaded using module load hdf5/<hdf5-version> and some of them correspond to parallel version of HDF5. However, there is also a default serial HDF5 installation (version 1.8.12) present in /usr/bin and /usr/lib. Thus, AX_LIB_HDF5() macro proceeds to search in the path first for serial installation (using h5cc compiler) and only if it is not found it looks for the parallel one (using h5pcc compiler). So even when parallel HDF5 module is loaded, it is not discovered due to existing installation in /usr/bin which is always seen first, no matter the order of PATH directories.
• Solution:
  1.1 Replace the call to AX_LIB_HDF5() in configure.ac with AX_LIB_HDF5([parallel]) so that the search proceeds directly to use hpcc, which correspond to the loaded module and not to the default HDF5 installation.
  1.2 Since in this case the parallel version is used, HDF5 headers will try to #include "mpi.h". If you get an error pointing to mpi.h : no such file or directory, then you need to load the MPI too. On curie, do something like module load openmpi/3.1.2-gcc-7.3.0.

2. Issue with PKG_CHECK_MODULES macro from pkg.m4:

• Bug: ./configure execution results in syntax error near unexpected token PKG_CFLAGS=""' or syntax error near unexpected token HDF5,' related to PKG_CHECK_MODULES macro from configure.ac.
• Solution:
  2.1. Execute aclocal -I m4 in TREXIO root directory before running autogen.sh or autoreconf -i. More details here: https://stackoverflow.com/questions/36659867/pkg-check-modules-syntax-error-near-luajit .
  2.2 On curie the aforementioned solution does not work, so one has to load the pkg-config module, i.e. module load apps/pkg-config-0.29.2-gcc-8.2.0).

[q-posev]

Something unrelated, but also observed on curie:

• Bug: in the output of ./configure execution there is checking for GNU libc compatible malloc... no line. After that make execution produces error undefined reference to 'rpl_malloc'. This issue comes from AC_FUNC_MALLOC built-in macro, which defines rpl_malloc if for some reason GLIBC-compatible malloc is not found/compiled. See, for example, this issue: maxmind/libmaxminddb#144
• Solution: This is a cross-compilation bug, where my experience is somewhat limited. One possible workaround here is to patch configure execution like this ac_cv_func_malloc_0_nonnull=yes ./configure <configure_flags_if_any>.