On 02/04/2024 21:29, Sebastian Ramacher wrote:
OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI.
So it is technically not a transition, but breaks 32-bit builds.
Doesn't make it better. This is not the time to do that without tests
builds and bugs filed.
The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH
builds on all archs, but testing all dependencies of the change has not been
tested, and I don't know how you would do that - setting up eg ratt to
rebuild all on 32-bit archs (as everything on 64-bit will not have changed.)
Beside the easy part of chaning mpi-defaults, I count 30 something
packages that have explicit build dependencies on libopenmpi-dev. None
of those packages has bugs filed to change to mpich on 32 bit
architectures.
To be honest, I don't see these two changes (changing mpi-defaults to
mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be
preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32
bit until the time_t transition is done.
Cheers
I checked with "build-rdeps libopenmpi-dev" and checked the packages.
They are mostly false-alarms.
What is needed:
* mpich not to use libpmix for 32-bit archs. I've a patch i'm testing.
* armci-mpi builds on both mpich, openmpi. Needs work to only build on
openmpi on 64-bit. #10683219
* code-saturne: Uses the default mpi version of hdf5. #1068318
* adios: fix just uploaded.
* vtk9: Depends on libhdf5-openmpi-dev instead of libhdf5-mpi-dev. #1068321
* trilinos: deps on openmpi , but only available on 64-bit systems. No
change needed
* hdf5: Needs to depend on 64-bit archs for libopenmpi-dev. #1068320
* scalapack: Needs to dep on 64-bit archs only for libopenmpi-dev. #1068322
Regards
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
