Installation problem (unexpected h5pfc script)


I have installed HDF5 many times in the past, and lately I’m doing the installation with Spack. This gave me no problems in several machines, but I’m now trying to figure out what is going on in one of them, which seems to compile and install HDF5 without issues, but then, when I check the contents of the installed h5pfc file, I get the following:

[gcc_930]  can30003@login1:.../stage/can30003> cat `which h5pfc`
#! /bin/sh
# Copyright by The HDF Group.
# Copyright by the Board of Trustees of the University of Illinois.
# All rights reserved.
# This file is part of HDF5.  The full HDF5 copyright notice, including
# terms governing use, modification, and redistribution, is contained in
# the COPYING file, which can be found at the root of the source code
# distribution tree, or in
# If you do not have access to either file, you may request a copy from

if [ ! -e "$prg" ]; then
  case $prg in
    (*/*) exit 1;;
    (*) prg=$(command -v -- "$prg") || exit;;
  cd -P -- "$(dirname -- "$prg")/.." && pwd -P
) || exit
prg=$dir/$(basename -- "$prg") || exit

printf '%s\n' "$prg"
printf 'dir is %s\n' "$dir"

export PKG_CONFIG_PATH=$dir/lib/pkgconfig

/storage/projects/can30/angelv/spack/opt/spack/linux-sles12-sandybridge/gcc-9.3.0/openmpi-4.1.1-kzrxkk5ksthmhgftmkin3bcflz7ezygc/bin/mpif90 `pkg-config --define-variable=prefix=$dir --cflags --libs hdf5_fortran-1.10.7` $@

Any ideas to help me chase the problem on why I could be getting this instead of the usual h5pfc script?


Spack now builds HDF5 with CMake instead of with Autotools as it did in the past. The h5pfc script, and the other compile scripts use pkgconfig and should work the same for compiling and linking application source files. If you experience compile/link failures, please report the nature of the specific.



well, the problem is there anytime I try to compile anything. It looks like the h5pcc and similar scripts are not what they should be (at least there are different to what I have in my other machines’ working environments), and so, for example a simple h5pfc -help will not work:

can30003@login1:.../CODES/PORTA-private> h5pfc -help
dir is /storage/projects/can30/angelv/spack/var/spack/environments/gcc_930_t/.spack-env/._view/wbqmdwysrmco4o3xdzvxhrw2wxbnww3q
gfortran: error: unrecognized command line option '-h'

Neither a simple compilation:

can30003@login1:.../CODES/PORTA-private> make
mkdir -p /storage/scratch/can30/can30003/CODES/PORTA-private/build 
h5pcc -O3  -DTHREAD_IO -pthread -DHANLE_ZEEMAN_FS  -shlib -DSMODE_FULL -std=c99 -Wl,--disable-new-dtags -c -I/storage/scratch/can30/can30003/CODES/PORTA-private/src  src/porta/parse_commands.c -o /storage/scratch/can30/can30003/CODES/PORTA-private/build/parse_commands.o
dir is /storage/projects/can30/angelv/spack/var/spack/environments/gcc_930_t/.spack-env/._view/wbqmdwysrmco4o3xdzvxhrw2wxbnww3q
gcc: error: unrecognized command line option '-shlib'
Makefile:80: recipe for target '/storage/scratch/can30/can30003/CODES/PORTA-private/build/parse_commands.o' failed
make: *** [/storage/scratch/can30/can30003/CODES/PORTA-private/build/parse_commands.o] Error 1

The CMake created cc scripts are based on using pkgconfig.

Thanks. As far as I can see, I have pkgconfig installed no problems. So, just to double check, the above commands (for example h5cc -help should work and give the help information regardless of whether we were using CMake or Autotools, right?

Probably not, the scripts were requested without any specs. Please enter an issue on github for improvements.

Thank you for reporting the issue! Could you please confirm that you expect the same flags and functionality for h5pfc and h5cc scripts?

The -help option is not so important, but with the new scripts I simply cannot compile our code, since it requires the compilation of shared libs, which is also giving trouble as unrecognized commad line option. Is there any workaround or an option to use the old autotools?

(when did the change to CMake happen? I didn’t think this would be a version problem, since the other installation I have is also using HDF5-1.10.7 without problems, and I can see that it was compiled with autotools?)

So at a minimum you would like a “use-static-lib” (only if both shared and static are built), right?
Have you tried to build a static only version of hdf5? Because the cc scripts will then use static libs? (as a workaround).


OK, I can see now that 1.10.7 can be installed with Autotools or with CMake, so that’s why it was working fine in my previous installation and not now. (I’m compiling HDF5 with Spack, and I didn’t realize that the Spack maintainers changed the compilation toolchain from Autotools to CMake on June’28, and my previous installation was done on June 22. I have now installed HDF5 1.10.7 with the Autotools Spack option, and h5cc was again as intended (or maybe I should just say, as I was used to).

To be honest, I’m not sure exactly what I’m expecting from these scripts :slight_smile:, but I would say that the options provided in the Autotools version were really useful. In my case, I’ve used many times the -show and -showconfig options. In this particular case, not having the -shlib option is a showstopper. By default (and I guess the most useful option) Spack will install HDF5 both with static and shared libraries. For our code, we need to create shared libraries, not static ones, so I’m not sure if there is a workaround for this…

In general I would say that it feels a bit awkward that being the same HDF5 version, these scripts behave and have different options depending on which compilation method is used.

You have me confused, if you need shared libs, why the need for -shlib option?

Maybe it is awkward, however, with CMake there are better ways to control projects built with HDF5. The cc scripts were just convenience scripts to quickly compile a small program (like the examples) without investing in the framework for a larger project.

Regarding the -shlib option, if I remember correctly, we had to add this to our makefiles, because the end user could be using an HDF5 installation with only static libraries, but we still need to generate shared libraries. If that doesn’t make sense, I’ll have to go back to my notes to remember properly…

OK, these were my notes on why I added the -shlib option at the time:

# -shlib added to avoid compilation messages like this, where the HDF5 library itself  
# should be compiled with -fPIC                                                                                                                                                                                      

# /usr/bin/ld: /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.a(H5LT.o):  
# relocation R_X86_64_PC32 against symbol `H5T_NATIVE_SCHAR_g' can not be used  
# when making a shared object; recompile with -fPIC

Unless expressly disabled, CMake builds should apply the PIC flag by default.