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): mpich-3.1.4-2.fc22 How reproducible: Every time 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 Actual results: Applications linked against mpich (or a derived library e.g. ptscotch-mpich) fail due to their libraries not being found. Expected results: Application should launch. Additional info: I created a file /etc/ld.so.conf.d/mpich-x86_64.conf with contents: /usr/lib64/mpich/lib 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. Jeesh!
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.