On 2026-03-19 11:47, Adrian Bunk wrote:
On Thu, Mar 19, 2026 at 02:13:25AM +0100, Drew Parsons wrote:
Source: petsc
Followup-For: Bug #1102465
As pointed out already in this bug, this warning is not a bug in
PETSc.
It is working entirely as intended.
No information was given with this bug reopening.
...
I forgot to unarchive the bug before sending the explanation,
but you should have received the personal copy of it:
Date: Wed, 18 Mar 2026 13:43:22 +0200
From: Adrian Bunk <[email protected]>
...
The bug is still present in 3.24.4+dfsg1-1 (see i386):
https://tracker.debian.org/pkg/mpich
...
∙ ∙ Autopkgtest for petsc/3.24.4+dfsg1-1: amd64: Pass, arm64: Pass,
i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass
...
I presume it refers to the 32-bit build failures of reverse
dependencies, which is happening due to the upgrade of mpich from v4
to >v5.
Yes.
petsc (and all other MPI packages) needs to be rebuilt against
the new mpich (on 32-bit arches)
(the mpich upgrade needs a transition bug).
...
If this is true, then mpich v5 needs a new soname (or at least a
package
rename) to ensure that packages built against v4 won't use v5.
One of the following claims is incorrect:
- mpich claims v5 is compatible with v4
- petsc claims v4 and v5 are incompatible
Thanks for the extra detail
I think part of the situation comes from the historical development of
the MPI implementations,
and from PETSc trying to manage bug reports coming from different MPI
libraries and their different versions.
True, mpich is still provided by libmpich12, so it's not a question of
transitioning libmpich4 to libmpich5 (I had forgotten that point).
So there is some ABI compatibility. It is possible that PETSc is being
over-sensitive due to problems that had been arising in the past but are
no longer a great problem.
The question of ABI compatibility will get even more complex, or simpler
depending on your perspective, in the future when the MPI
implementations move to MPI standard 5, which will provide a common
stable ABI that will enable swap-out between OpenMPI and MPI (and other
implementations). I say "future", but actually that's what mpich v5 is
already, it's supporting the new MPI-5 standard.
The apparent compatibility that we're seeing between mpich v4 and v5
might be part of that move to a more stable interface, which is a new
development. Once the MPI-5 standard and its common ABI is fully
implemented and operating (i.e. once users are routinely using openmpi
v5 or mpich v5), I can expect PETSc upstream will be able reevaluate and
relax their version tests (at the moment their attention is on ensuring
past library versions continue to work, with, as an example of the types
of bugs they have to deal with, nvidia's cuda fortran compiler still not
supporting an 8-year-old fortran standard [1]).
In the short term I think the simplest thing right now for petsc is to
just rebuild for the new version 3.24.5, which will reset the 32-bit
builds to mpich v5.
Beyond that, perhaps both the openmpi and mpich packages will want to be
reconfigured so they can equally and alternatively be installed as the
preferred MPI on any system. The situation would then probably be
similar to what we do with BLAS/LAPACK and the various alternative
optimised BLAS implementations.
Drew
[1] true story. https://gitlab.com/petsc/petsc/-/work_items/1879
