Gilles,
Yes, that works. i see the m4 code that checks for it in
config/opal_check_pmi.m4.
It's a little deceptive because you will only see the check for
/usr/include/slurm belowafter the slurm headers are installed and only if you
supply no parameter. If you do
supply a path to --with-pmi
Phil,
Did you simply try `--with-pmi` ?
According to the configury macros, we look for /usr/include/pmi.h and then
/usr/include/slurm/pmi.h, so that should work just fine.
If not, can you please compress and post your config.log ?
Cheers,
Gilles
Phil K via devel wrote:
>Exactly. Sorry if m
Exactly. Sorry if my opener was long-winded and obscure. You can see below
OMPI finds the pmi libraries, but misses the headersbecause it's adding
"/include" to my path which I don't want it to do.
./configure --with-pmi=/usr/include/slurm --with-pmi-libdir=/usr
checking if user requested PMI
Okay, so this has nothing to do with the internal pmix or the pmi-1/2 headers
it provides, which is what confused me. You are building the SLURM pmi support
for OMPI, which does indeed use the slurm-provided headers and pmi libraries.
Someone can take a look at that as it should check first in t
The issue is getting through the OMPI configure without error which you
_cannot_ when using --with-pmi=/usr/include/slurm if pmi.h and pmi2.h are
installed *only* in /usr/include/slurm.
On Saturday, September 2, 2017 9:55 AM, "r...@open-mpi.org"
wrote:
I’m honestly confused by this
I’m honestly confused by this as I don’t understand what you are trying to
accomplish. Neither OMPI nor PMIx uses those headers. PMIx provides them just
as a convenience for anyone wanting to compile a PMI based code, and so that we
could internally write functions that translate from PMI to the
I just wanted to share a workaround I came up with for this openmpi configure
issue.
When specifying header paths in configure, openmpi adds an /include subpath the
--with-pmi specifier(and others). This is documented very clearly. Recently,
in switching over to internal pmix, I wanted to rip
