Actually if you're set on installing pmix/pmix-devel from the rpms and then
configuring slurm manually,you could just move the pmix-installed versions of
libpmi.so* and libpmi2.so* to a safe place, configureand install slurm which
will drop in its versions pf those libs and then either use the slurm versions
or movethe the pmix versions of libpmi and libpmi2 back into place in
/usr/lib64.
On Tuesday, November 28, 2017 5:32 PM, Philip Kovacs <[email protected]>
wrote:
This issue is that pmi 2.0+ provides a "backward compatibility" feature,
enabled by default, which installsboth libpmi.so and libpmi2.so in addition to
libpmix.so. The route with the least friction for you would probablybe to
uninstall pmix, then install slurm normally, letting it install its libpmi and
libpmi2. Next configure and compilea custom pmix with that backward feature
_disabled_, so it only installs libpmix.so. Slurm will "see" the pmix
libraryafter you install it and load it via its plugin when you use --mpi=pmix.
Again, just use the Slurm pmi and pmi2 and install pmix separately with the
backward compatible option disabled.
There is a packaging issue there in which two packages are trying to install
their own versions of the same files. That should be brought to attention of
the packages. Meantime you can work around it.
For PMIX:
./configure --disable-pmi-backward-compatibility // ... etc ...
On Tuesday, November 28, 2017 4:44 PM, Artem Polyakov <[email protected]>
wrote:
Hello, Paul
Please see below.
2017-11-28 13:13 GMT-08:00 Paul Edmon <[email protected]>:
So in an effort to future proof ourselves we are trying to build Slurm against
PMIx, but when I tried to do so I got the following:
Transaction check error:
file /usr/lib64/libpmi.so from install of slurm-17.02.9-1fasrc02.el7.cen
tos.x86_64 conflicts with file from package pmix-2.0.2-1.el7.centos.x86_64
file /usr/lib64/libpmi2.so from install of slurm-17.02.9-1fasrc02.el7.cen
tos.x86_64 conflicts with file from package pmix-2.0.2-1.el7.centos.x86_64
This is with compiling Slurm with the --with-pmix=/usr option. A few things:
1. I'm surprised when I tell it to use PMIx it still builds its own versions of
libpmi and pmi2 given that PMIx handles that now.
PMIx is a plugin and from multiple perspectives it makes sense to keep the
other versions available (i.e. backward compat or perf comparison)
2. Does this mean I have to install PMIx in a nondefault location? If so how
does that work with user build codes? I'd rather not have multiple versions of
PMI around for people to build against.
When we introduced PMIx it was in the beta stage and we didn't want to build
against it by default. Now it probably makes sense to assume --with-pmix by
default.I'm also thinking that we might need to solve it at the packagers level
by distributing "slurm-pmix" package that is builded and depends on the pmix
package that is currently shipped with particular Linux distro.
3. What is the right way of building PMIx and Slurm such that they
interoperate properly?
As for now it is better to have a PMIx installed in the well-known location.
And then build your MPIs or other apps against this PMIx installation.Starting
(I think) from PMIx v2.1 we will have a cross-version support that will give
some flexibility about what installation to use with application,
Suffice it to say little to no documentation exists on how to properly this, so
any guidance would be much appreciated.
Indeed we have some problems with the documentation as PMIx technology is
relatively new. Hopefully we can fix this in near future.Being the original
developer of the PMIx plugin I'll be happy to answer any questions and help to
resolve the issues.
-Paul Edmon-
--
С Уважением, Поляков Артем Юрьевич
Best regards, Artem Y. Polyakov
