Can someone provide an example of using the rpmbuild command while specifying
the slurm.spec-legacy file?
I need to build the new version of slurm for RHEL6 and need to invoke the
slurm.spec-legacy file (if possible) on this command line:
# rpmbuild -tb slurm-17.11.1.tar.bz2
Regards, Ruth
R. B
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 in
I would extract the archive and then do:
rpmbuild -ba slurm.spec-legacy
That's at least how I've been handling it.
-Paul Edmon-
On 12/21/2017 10:40 AM, Braun, Ruth A wrote:
Can someone provide an example of using the rpmbuild command while
specifying the slurm.spec-legacy file?
I need to
Hmmm - I think there may be something a little more subtle here. If you build
your app and link it against “libpmi2”, and that library is actually the one
from PMIx, then it won’t work with Slurm’s PMI2 plugin because the
communication protocols are completely different.
So the fact is that if
>(they are nothing more than symlinks to libpmix)
This is very helpful to know.
On Thursday, December 21, 2017 3:28 PM, "r...@open-mpi.org"
wrote:
Hmmm - I think there may be something a little more subtle here. If you build
your app and link it against “libpmi2”, and that library is a
hello,
I want to build a many-to-many relationship of qos and partition like what
is shown in NERSC website: http://www.nersc.gov/users/computational-systems/
cori/running-jobs/queues-and-policies/
I need to correct myself - the libs are not symlinks to libpmix. They are
actual copies of the libpmix library with their own version triplets which
change only if/when the PMI-1 or PMI-2 abstraction code changes. If they were
symlinks, we wouldn’t be able to track independent version triplets.
