Hello all,
yes, I have noticed that with the individual development libraries for a very
long time, because I rather compile the entire products by HAND to my needs
myself and do not want to rely on the libraries of the individual Linux -
variants.
I have done very well with this at the moment
Hello Gilles,
thank you very much for the prompt patch.
I can confirm that configure now prefers the external PMIx. I can
confirm that the munge warnings and PMIx errors we observed are gone. An
mpi hello world runs successfully with srun --mpi=pmix and --mpi=pmi2.
I noticed that configure comp
Christof,
Open MPI switching to the internal PMIx is a bug I addressed in
https://github.com/open-mpi/ompi/pull/11704
Feel free to manually download and apply the patch, you will then need
recent autotools and run
./autogen.pl --force
An other option is to manually edit the configure file
Look
Hello Z. Matthias Krawutschke,
On Fri, May 19, 2023 at 09:08:08PM +0200, Zhéxué M. Krawutschke wrote:
> Hello Christoph,
> what exactly is your problem with OpenMPI and Slurm?
> Do you compile the products yourself? Which LINUX distribution and version
> are you using?
>
> If you compile the sof
Hello Christoph,
what exactly is your problem with OpenMPI and Slurm?
Do you compile the products yourself? Which LINUX distribution and version are
you using?
If you compile the software yourself, could you please tell me what the
"configure" command looks like and which MUNGE version is in use
Hello again,
I should add that the openmpi configure decides to use the internal pmix
configure: WARNING: discovered external PMIx version is less than internal
version 3.x
configure: WARNING: using internal PMIx
...
...
checking if user requested PMI support.
Hello everybody,
we are seeing the sypmptoms described in
https://github.com/open-mpi/ompi/issues/11557
However, according to the systems package manager (dnf) all munge
related packages on the build node and the execution node are identical,
see details at the bottom. So, the explanation given b
