Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version

[Alastair McKinstry]

On 19/03/2026 11:49, Drew Parsons wrote:
> 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

>>>
>> 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.
>
There is (supposed to be) no transition; MPI standard v5 designates a 
standard ABI, but no change in the API.

I will need to dig into PETSc to understand how it sees two versions.

MPICH provides a new libmpi_abi.so that supplies the new ABI, so as to 
not break libmpich.so.12

I will need to see if this is specified in v5, or what OpenMPI is 
expected to do.

> 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.
>
  Yes, work will be needed in both to make them intercompatible.

Alastair

> Drew
>
> [1] true story.  https://gitlab.com/petsc/petsc/-/work_items/1879