Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#60041 - [hdf5-openmpi] Fortran compilation cannot find module

Attached to Project: Community Packages
Opened by Martin Diehl (MartinDiehl) - Thursday, 13 September 2018, 07:32 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Monday, 24 September 2018, 18:31 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ronald van Haren (pressh)
Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


For your information: I've submitted below bug report to

Maybe it makes sense to create symlinks from either /usr/include/static/*.mod or /usr/include/share/*.mod to /usr/include, but that would be in my eyes just a workaround for a bug that should be fixed upstream. Don't know if that is good practice.


Martin Diehl,

location of module files (Fortran) non-standard

Arch Linux
Linux quadcore 4.18.4-arch1-1-ARCH #1 SMP PREEMPT Wed Aug 22
07:33:26 UTC 2018 x86_64 GNU/Linux

GCC 8.2

The standard search location for Fortran module files (*.mod,
similar use as header files in C) is /usr/include. With the current
builds, the HDF5 module files are stored in /usr/include/static and
/usr/include/shared. When compiling my application, they are therefore
not found. This behaviour seems especially unreasonable to me as there
is (and to my knowledge) will never be a difference between the static
and shared version because the *.mod files are directly generated from
the source code. The only possible way to have different shared and
static *.mod files would be the use of different versions of HDF5 for
static and shared libraries. But that seems to be the first step to a
version hell, so in my opinion one should not support such setups by
default, especially at the cost that more standard setups are not
working anymore

- unpack current archive "hdf5-1.10.3.tar.bz2"
- create a directory "build" in "hdf5-1.10.3" and cd into it
- run: CXX="mpicxx" CC="mpicc" FC="mpif90" F9X="mpif90"
RUNPARALLEL="mpirun" OMPI_MCA_disable_memory_allocator=1 cmake ..
- run: cmake --build . --config Release
- run: make DESTDIR=/ install

This task depends upon

Closed by  Bruno Pagani (ArchangeGabriel)
Monday, 24 September 2018, 18:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  hdf5{,-openmpi} 1.10.3-2.
Comment by Martin Diehl (MartinDiehl) - Monday, 24 September 2018, 05:27 GMT
Turns out that the location depends on the build system: When building with configure, the Fortran module files are not stored in the subfolders 'shared' and 'static' even if shared and static libraries are build. Also, the name of the high level Fortran libraries depend on the build system. For cmake the name is libhdf5_hl_fortran and for configure it is libhdf5_fortran.

The HDF5 developers have been informed about this
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 24 September 2018, 12:26 GMT
Yes. By me too. A while ago:

I’m going to push a new package mixing CMake and autotools builds to keep the benefits of each without their respective issues.

Should be up latter today.