RHEL 6.6 MPI mess

Dave Love d.love at liverpool.ac.uk
Thu Oct 30 17:28:04 UTC 2014

Doug Ledford <dledford at redhat.com> writes:

> There was a changeover in maintainership for this package internally, so
> I'm coming into this issue cold.

Thanks for responding.  (I assume that means the Red Hat openmpi
package.)  I wasn't expecting to get it sorted out in RHEL, and wanted
to avoid what looks like being mess in EPEL.

> My apologies for that.  Have you
> installed the compat-openmpi package and do things still break with that
> installed (at least for openmpi, mpich is another matter entirely)?

Yes, but it's v 1.4.  It clearly doesn't allow packages built against
1.6 to install, and it's not a dependency of openmpi-1.8.  I don't now
have the test installation I used earlier, but the following is on a
production system which uses a self-built 1.6 package as a compatible
upgrade from 1.5 versus a rebuilt Fedora 1.8, modified to install in
parallel.  The program was built against 1.6.

  $ rpm -q compat-openmpi
  $ ldd mpi-hello | grep libmpi_f
  	libmpi_f90.so.1 => /usr/lib64/openmpi/lib/libmpi_f90.so.1 (0x00007fb261161000)
  	libmpi_f77.so.1 => /usr/lib64/openmpi/lib/libmpi_f77.so.1 (0x00007fb260f2d000)
  $ module switch openmpi-x86_64 mpi/openmpi_18-x86_64
  $ ldd mpi-hello | grep libmpi_f
  	libmpi_f90.so.1 => not found
  	libmpi_f77.so.1 => not found
I'm not actually interested in mpich, other than for packaging things
according to Fedora guidelines, so I can't say much about that, other
than it won't upgrade either.  We have mvapich for occasional use with
MPI_THREAD_MULTIPLE, but the current version seems compatible with the
one package I've built against mvapich.

> The other alternative (although not a good one for EL6, but could be
> used in EL7 and I believe is what's used in Fedora, although it's been a
> long while since I help define the Fedora MPI policies so I could be
> wrong) would be to make multiple versions of openmpi install side by
> side without ever doing an upgrade.

The policy appears to allow that if you abuse the compiler variable as a
version (as above) though you have to fix the spec file more than that.

> Then newer openmpi releases would,
> at most, change the default environment but leave the older environment
> selectable via modules, allowing a user to simply select the old
> environment and keep on running.

The reason you might want a (modified) 1.5/6 and a 1.8 anyhow is that
1.8 has lost checkpointing, at least, while gaining things like
apparently-better mpi-io, which would be of interest if I was allowed to
run pvfs.  I'd guess most sites won't run vanilla openmpi packages, but
still want to install packages built against them (at least what seems
to be the minority which believe in packaging).

I must say I don't understand why these changes were made, let alone not
documented.  It's not just linking/dependencies, but more which is
affected at runtime <https://bugzilla.redhat.com/show_bug.cgi?id=1158864>.

More information about the devel mailing list