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/libpmi2 > and 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 pmi > calls 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.
