OK, so slurm's libpmi2 is a functional superset of the libpmi2 provided by pmix
2.0+. That's good to know.
My point here is that, if you use slurm's mpi/pmi2 plugin, regardless of which
libpmi2 is installed, slurm or pmix, you will always run the slurm pmi2 code
since it is compiled directly into the plugin.
On Wednesday, December 20, 2017 10:47 PM, "r...@open-mpi.org"
<r...@open-mpi.org> wrote:
On Dec 20, 2017, at 6:21 PM, Philip Kovacs <pkde...@yahoo.com> wrote:
> -- slurm.spec: move libpmi to a separate package to solve a conflict with the
> version provided by PMIx. This will require a separate change to PMIx as
> well.
I see the intention behind this change since the pmix 2.0+ package provides
libpmi/libpmi2and there is a possible (installation) conflict with the Slurm
implementation of those libraries. We've discussed that issue earlier.
Now, suppose a user installs the pmix versions of libpmi/pmi2 with the
expectation that pmicalls will be forwarded to libpmix for greater speed, the
so-called "backward compatibility" feature.
Shouldn't the Slurm mpi_pmi2 plugin attempt to link with libpmi2 instead of its
internal implementation of pmi2? As it stands now, there won't be any
forwarding of pmi2 code to libpmix which I imagine users would expect in that
scenario.
Sadly, it isn’t quite that simple. Most of the standard PMI2 calls are covered
by the backward compatibility libraries, so things like MPICH should work
out-of-the-box.
However, MVAPICH2 added a PMI2 extension call to the SLURM PMI2 library that
they use and PMIx doesn’t cover (as there really isn’t an easy equivalent, and
they called it PMIX_foo which causes a naming conflict), and so they would not
work.
