Re: OpenMPI 5.0 to be 32-bit only ?
On 13/02/2023 12:51, Adrian Bunk wrote:
On Mon, Feb 13, 2023 at 10:59:18AM +0000, Alastair McKinstry wrote:
The case we should make is that "no one cares about 32-bit builds" from
the starting post in the GitHub issue is not true for Debian.
We do care that it *builds*, even if it might not be actually used.
I've been making this point, mostly in the context of avoiding a future
where no MPI is available on 32-bit
(and by implication, essentially forking Debian into a toy 32-bit world and
a properly-supported 64-bit one).
I don't see what important functionality for 32-bit today would be
missing without MPI, it is just more work and breakages to have packages
configured differently on different platforms to continue providing the
functionality that is still important.
There are a significant number of science libraries dependent on MPI.
We would need to do MPI-free builds of these libraries; I'm not sure how
much breaks as we do.
The point of going 64-bit only is to clean up data structures and remove
technical debt: Hence 5.x will start a cleanup and removal of 32-bit code.
The next point release may work on 32-bit by just bypassing the compilation
flag; ongoing support starts meaning more invasive patches need to be
carried by us.
This sounds as if the lesser evil for us will be to configure packages
differently when one or all MPI implementations are going away on 32-bit.
ffmpeg -> codec2 -> octave -> sundials -> sundials does not build with MPICH
One of these four arrows must be broken.
That's work and not fun work, but likely the lesser evil.
I suspect that the real problem may be the support of underlying
libraries shared by both implementations,
eg PMIx. If we can keep a version of MPI that works on generic hardware
(TCP/IP) we may be ok.
ph: +353 87 6847928 e: email@example.com, im: @sceal.ie:mckinstry