h5pcc is showing an unexpected default configuration:

$ h5pcc --showconfig
gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5_hl.a /usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.a -lcrypto -lcurl -lsz -lz -ldl -lm -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi

Note how it includes static linking to libhdf5_hl.a and libhdf5.a

I would expect the default configuration to use dynamic linking with
shared libraries, as in

$ h5pcc --showconfig -shlib
gcc -I/usr/include/hdf5/openmpi -L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -lhdf5_hl -lhdf5 -lcrypto -lcurl -lsz -lz -ldl -lm -Wl,-rpath -Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi

As far as I can tell, the default static linking is causing the RC
Bug#1020054 reported against h5py.

Should the default configuration of h5pcc be changed to confirm with
the -shlib configuration?

Hi Drew,

Drew Parsons a écrit le 04/11/2022 à 11:27 :

This is the expected behavior as documented by upstream:

        -shlib Compile with shared HDF5 libraries [default for hdf5
built without static libraries]

        -noshlib
               Compile with static HDF5 libraries [default for hdf5
built with static libraries]
          PYBUILD_NAME=$(PYBUILD_NAME_MPI) CC=h5pcc HDF5_USE_SHLIB=yes
HDF5_MPI=ON HDF5_PKGCONFIG_NAME=hdf5-mpi H5PY_SYSTEM_LZF=1 dh_auto_build
-D $(BUILD_DIR_MPI)

I don't think so since the current behavior is the documented one.

Best,
_g.

...
...


I agree, we should stick with upstream's documented behaviour.  There
could be room for some discussion or interpretation, unless I'm
misunderstanding upstream's intent here.  In our case we're providing
hdf5 built both with and without static libraries. In that case we could
argue for setting -shlib as default, if we expect client programs
normally to use the shared library (are there  arguments in favour of
using the static library even if the shared library is available?)

On the other hand, the h5pcc documentation for the HDF5_USE_SHLIB
environment variable is a bit less ambiguous:
"default: no except when built with only shared libraries". That makes
it more clear that upstream expects the static library to be used when
available, even if the shared library is available.

...

Fair, especially since the HDF5_USE_SHLIB documentation makes upstream's
intention clear.

It's strange that Bug#1020054 was only recently reported.  h5py was
building happily until now. Would it be the upgrade to gcc-12 that
changed the behaviour?


I'll update the h5py configuration in any case as you recommend
(assuming we still want to be using the shared library for debian
packages).

...


h5py is building fine against the shared libraries with
HDF5_USE_SHLIB=yes, but leaves a question about rpath.

Notice that `h5pcc --showconfig -shlib` includes
"-L/usr/lib/x86_64-linux-gnu/hdf5/openmpi -lhdf5_hl -lhdf5 -Wl,-rpath
-Wl,/usr/lib/x86_64-linux-gnu/hdf5/openmpi"

The h5py python extensions get linked with this, such the h5py .so files
are generated with
   NEEDED               libhdf5_openmpi.so.103
   RUNPATH              /usr/lib/x86_64-linux-gnu/hdf5/openmpi

In normal package policy we try to remove RUNPATH, and in the case of
the hdf5 libraries libhdf5_openmpi.so.103 is available in the standard
library path at /usr/lib/x86_64-linux-gnu/.  In fact
libhdf5_openmpi.so.103 is not even found in
/usr/lib/x86_64-linux-gnu/hdf5/openmpi (instead libhdf5.so is found
there as a symlink to ../../libhdf5_openmpi.so).

As far as I can tell, the -rpath entry in the h5pcc configuration is
redundant, possibly even wrong (since the linked library is
libhdf5_openmpi.so.103, not the more general libhdf5.so)

Should rpath be removed from the h5pcc shlib configuration?

Hi Drew,

Drew Parsons a écrit le 15/11/2022 à 16:28 :

I've just uploaded hdf5 1.10.8+repack-2 which should fix this issue.

Best,

_g.