See in part the discussion upstream at :
https://github.com/open-mpi/ompi/issues/8596
One workaround might be to use the internal pmix. 4.1.0-4 worked, and
using the internal pmix works, BUT reverting to using internal pmix has
big testing consequences:
We'd move libpmix.so.2 from the external libpmix ($LIBDIR/libpmix.so.2)
to libopenmpi3 ($LIBDIR/openmpi/lib/libpmix.so.2) also involves
including pmix headers in libopenmpi-dev and re-testing apps accordingly.
Currently libopenmpi-dev depends on libpmix-dev , which means
'build-rdeps libpmix-dev' lists 313 packages.
Fortunately only the pmix and openmpi source packages are really
involved (mpich 3.4.1 didn't correctly work with libpmix so its not
built with it - a flag/hint?) but if we simply move to internal pmix we
will be shipping 2 sets of pmix headers. I get 4.1.0-4 to work only by
excluding libpmix-dev when building to avoid accidental collisions. We
could put Build-Conflicts: libpmix-dev into openmpi but we need to test
this.
Regards
Alastair
--
Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
