Bug#1102928: mpich: mpi-defaults autopkgtest regressions on 32-bit

[Simon McVittie]

On Sun, 13 Apr 2025 at 13:14:49 +0300, Adrian Bunk wrote:
>214s autopkgtest [01:51:54]: test mpi-compile-run-cc-pkgconf-mpi-c: [-----------------------
>214s Package mpi-c was not found in the pkg-config search path.
...
>This is related to two lines disappearing from the
>libmpich-dev postinst:
>
> --slave /usr/lib/i386-linux-gnu/pkgconfig/mpi-c.pc mpi-c.pc-i386-linux-gnu /usr/lib/i386-linux-gnu/pkgconfig/mpich.pc \
> --slave /usr/lib/i386-linux-gnu/pkgconfig/mpi-fort.pc mpi-fort.pc-i386-linux-gnu /usr/lib/i386-linux-gnu/pkgconfig/mpich.pc
>
>
>Re-adding the first line fixes mpi-compile-run-cc-pkgconf-mpi-c.
>
>
>Fixing mpi-compile-run-f90-pkgconf-mpi* requires re-adding the second line,
>plus reverting the following change:
>
>/usr/lib/i386-linux-gnu/mpich/lib/pkgconfig/mpich.pc
> -Libs:  -Wl,-z,relro -Wl,-z,now -L${libdir} -lmpichfort -lmpich   -lpthread  -lhwloc
> +Libs:  -Wl,-z,relro -Wl,-z,now -L${libdir} -lmpich   -Wl,-z,relro -Wl,-z,now  -lpthread   -lhwloc

On Wed, 16 Apr 2025 at 12:07:36 +0100, Alastair McKinstry wrote:
>I'm reluctant to make these changes for mpich as it recently 
>(upstream) dropped mpi-fort.pc support.

I believe the absence of mpi-c.pc might also be what is causing valgrind
to FTBFS on 32-bit architectures, preventing an unrelated RC bug fix from
migrating to testing (which I've reported as a separate bug, initially
against src:valgrind, but it might get reassigned to mpich).

Fixing the C regression by reinstating the first --slave line
seems considerably simpler, and might be enough to fix valgrind on
32-bit. Should we clone this bug into a C part which can certainly be
fixed, and a Fortran part which might need further discussion?

(If the package still contains a libmpichfort that can be linked against,
then it doesn't actually seem particularly hard to retain backward
compatibility with mpi-fort.pc for trixie either, but perhaps there are
subtleties that I'm not aware of.)

>I'd prefer we drop these tests in mpi-default for mpich in trixie than 
>add code to support in Debian, especially at this late stage.

Has this change been coordinated with mpi-defaults, and consumers of the
mpi-fort interface if any?

I understand your concern about the late stage of the release cycle, but
I also notice that mpich 4.3.x was first uploaded to unstable 2 days
before the toolchain freeze, which doesn't seem like an ideal time to be
dropping functionality that previously existed and may have been relied on
by dependent packages.

     smcv