Red Hat Bugzilla – Bug 1264887
mpich: Needs to install a dynamic linker hints file for sub-packages
Last modified: 2015-11-16 12:39:36 EST
Description of problem:
mpich (and sub-packages linked with it) store library files in /usr/lib64/mpich/lib which the dynamic linker knows nothing about.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install an application requiring a mpich linked library e.g. gmsh
2. Execute the application and notice libraries are not resolved e.g. libscotch.so.0 for gmsh
Applications linked against mpich (or a derived library e.g. ptscotch-mpich) fail due to their libraries not being found.
Application should launch.
I created a file /etc/ld.so.conf.d/mpich-x86_64.conf with contents:
then ran ldconfig and the appropriate libraries are now found and gmsh runs.
To get access to mpi-implementation-specific directories, please do
module load mpi/mpich-x86_64
This (amongst other things) sets LD_LIBRARY_PATH.
You can also do this permanently, by installing mpich-autoload.
So, let me get this right!
mpich installs libraries in /usr/lib/mpich/lib and does nothing to make those libraries known to the dynamic linker.
Applications which make use of those libraries then fail to start because the libraries cannot be found.
By some *magic* the end-user is supposed to know to run some obscure command or install another package which is not a dependency of mpich to allow the application to run.
How the heck is that NOTABUG? If a package installs a GUI application it should run out-of-the-box not need manual intervention.
There is more than one mpi implementation. They conflict with one another. Therefore what you propose (always enabling the libraries) is not possible in general. modulefiles are a standard mechanism to achieve runtime switching of optional components like this.