/usr/lib64/libhdf5* vs. /usr/lib64/openmpi/lib/libhdf5*

On our RHEL 6.6 machines we have the following two packages installed

hdf5-1.8.5.patch1-7.el6.x86_64 (provides /usr/lib64/libhdf5*)
hdf5-openmpi-1.8.5.patch1-7.el6.x86_64 (provides /usr/lib64/openmpi/lib/libhdf5*)

These seemingly provide what I would think are duplicate libraries (i.e. libhdf5.so.6.0.4), but doing an md5sum reveals that they are not identical.

1) Is this a bad practice / actual problem? One of our users claims having such duplicate libraries creates a dependency nightmare for him.

2) Assuming it is a problem, how do we "fix" it? Removing one or the other might break things for other people who are depending on the package we delete.

2 Answers

It shouldn't be a problem. If you are writing parallel code, you link to the parallel/OpenMPI version.

This Fedora page notes that they are built from the same source, so that strongly implies they have been tested in the configuration presented and shouldn't conflict.

These are not duplicate libraries and it is neither a bad practice nor an actual problem. HDF5 could be built with or without support for MPI. When built with MPI support, the HDF5 library can only be linked with applications that are also built against the same MPI library. That's why there are separate HDF5 packages:

  • hdf5-1.8.5 - non-MPI-enabled build to be used within non-MPI applications
  • hdf5-openmpi-1.8.5 - MPI-enabled build, uses Open MPI
  • hdf5-mpich-1.8.5 - MPI-enabled build, uses MPICH

The actual shared objects are installed in different places so that they could co-exist on the same system.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

You Might Also Like