Openmpi not added to the PATH during installation

Support
1

Is this the place to report issues/bugs with AlmaLinux 9?

When installing openmpi, it was not added to the PATH

Adding: export PATH=/usr/lib64/openmpi/bin:$PATH to the .bashrc solves the problem but the PATH variable should be set automatically during installation. This is probably a bug.

2

that’s not a bug, you’d be pretty ill advised to add every bit of software to your $PATH, especially globally.

you’ll just have to call it using /usr/lib64/openmpi/bin/opal_wrapper, or manually add it to your user’s $PATH via ~/.bashrc as you say.

3

I didnt talk about "every bit of software" but openmpi and I dont remember another distribution not taking care of this openmpi setting so the compiler finds openmpi to compile software with an openmpi dependency.

If that`s the RHEL way, fine with me, I figured it out but absolute beginners will have problems I think.

4

its a packaging nuance, potentially other distro’s are symlinking or installing into /bin which would already be in your $PATH, /usr/lib64 does seem odd.

p.s. i meant that rpm/dnf cannot update your user’s $PATH as it doesn’t know about users other than root, and you wouldn’t want every package you install outside of /bin to be inserted into everyone’s $PATH.

5

Indeed. There could be multiple implementations and then one can’t have them all “first on path”.

For example, EL7 had 32bit openmpi, 64bit openmpi, 32bit mpich, and 64bit mpich.

A package environment-modules is installed as dependency of openmpi.

You can run module av to see list of available “modules”. There is probably mpi/openmpi-x86_64

You can run module show mpi/openmpi-x86_64 to see what the module would set.

You can run module add mpi/openmpi-x86_64 to load those settings to your bash environment. (Or module add mpi, if mpi/openmpi-x86_64 is lexicographically greatest mpi/*)

You can run module list to see what you have added, and module purge to unload them all.
In other words, the module makes it easy to modify PATH (and other vars) on-the-fly.

6

Sorry for the late response. but I’ve not been able to link my openmpi installation correctly using PATH. To be clear, the problem is whenever I do a “sudo make install” on a program (hdf5-mpi in my case). The sudo will not looking in my PATH variable, even if I use -E.

I also tried module load mpi/openmpi before but it doesn’t work either. What should be the solution, as redefining every call to mpicc in the installation script looks like a wrong solution?

7

First, I’d avoid the ‘sudo’ altogether. Give the ‘configure’/‘cmake’/whatever a prefix that your regular account can write to. For example, the ~/.local Then you don’t need sudo at all.

Second, I guess that you (or build instructions) shortcut the

./configure
make
make install

into

./configure
make install

Yes, the ‘install’ target probably requires the build step to be complete, i.e. it both builds and then installs (copies files) in one go. Convenient, but …

The sudo make is same as user root logs in, changes to pwd, and runs make. It will not do module load mpi nor inherit shell environment from your session. Hence a different PATH.

Do you really need that application. Doesn’t EPEL have something like that?

$ dnf -q --enablerepo=epel list hdf5\*
Installed Packages
hdf5.x86_64                      1.12.1-7.el9.1        @epel
hdf5-devel.x86_64                1.12.1-7.el9.1        @epel
Available Packages
hdf5-mpich.x86_64                1.12.1-7.el9.1        epel 
hdf5-mpich-devel.x86_64          1.12.1-7.el9.1        epel 
hdf5-mpich-static.x86_64         1.12.1-7.el9.1        epel 
hdf5-openmpi.x86_64              1.12.1-7.el9.1        epel 
hdf5-openmpi-devel.x86_64        1.12.1-7.el9.1        epel 
hdf5-openmpi-static.x86_64       1.12.1-7.el9.1        epel 
hdf5-static.x86_64               1.12.1-7.el9.1        epel
8

I’ve added a new directory called installation_folder in my .local environment. But I prefer to use my own compiled version of hdf5 as it is easier to control HDF5 itself.

However, I’ve had an annoying bug where, by installing texlive, dnf decided to install its version of hdf5 and to overwrite all of my environment variable.

Needless to say, this broke all my previously installed program and now I got to try to reinstall all my program. I assume it is a bug since Openmpi was carefully installed to make sure nothing was overwritten.

9

Really? The EPEL’s hdf5 packages do install to “system locations” (/usr/{lib64,bin,include}) but do not add anything into /etc/profile.d/. I.e. they should not define any environment variables for shell sessions. Even if they would, packages should not overwrite anything within users’ homes.

10

Thanks for the quick reply. I’ve tried to understand what has been happening and I think I’ve got misguided by some installation problem in the program I’ve been using.

  1. I’ve installed hdf5-mpi and my program suite.
  2. I have, by mistake installed hdf5 using dnf.
  3. My program wasn’t able to run anymore.
  4. I tried to reinstall my program by precising the path of my hdf5 mpi installation. (Didn’t work)
  5. I uninstalled dnf hdf5.
  6. I tried to reinstall my program once again (Didn’t work)
    At this point, I assumed was due to the environment being somehow different before and after installing hdf5.

However, there seem to be a difference if I let the program chose the installation path/flags or if I give the same variable manually (As I had the installation log of the installation which worked). The only fix I was able to do was to uninstall dnf hdf5 and let the program run the configure script by itself.

I still don’t understand the exact cause, but your quick reply helped me into understanding what to look into and that my assumption about the issue was wrong.