Source: valgrind
Version: 1:3.24.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-arm@lists.debian.org, debian-powerpc@lists.debian.org, mpich@packages.debian.org
User: debian-arm@lists.debian.org
Usertags: armhf
User: debian-qa@lists.debian.org
Usertags: i386
User: debian-powerpc@lists.debian.org
Usertags: powerpc

While checking why the fix for #1057621 wasn't migrating to testing, I
noticed that the updated valgrind has failed to build on armhf and i386,
as well as the -ports architecture powerpc. (This means that it built
successfully on every 64-bit architecture that it supports, but failed
to build on every 32-bit architecture.)

The build failure:

1:3.24.0-2 built successfully, but it seems unlikely for this to have
been triggered by the only change in 1:3.24.0-3, which was the fix
for #1057621,
<https://salsa.debian.org/debian/valgrind/-/commit/2528eb684823b991035092bd27bd4ff354d22914>
which seems to be unrelated to the error message. Instead I think this
must have been triggered by a change in some other package - perhaps
mpich, which is the MPI implementation used on 32-bit? - between
2025-01-22 and 2025-04-13.

I see that valgrind's configure check for mpi-c is failing:

This might be related to the mpich and mpi-defaults autopkgtest
regressions seen with the version in unstable, #1102928 and #1089694.
If this is really a mpich regression, the bug can be reassigned to mpich
with an "affects" on src:valgrind.

Thanks,
    smcv

...

It looks like this is a combination of two factors.

One is that 32-bit architectures use mpich, which dropped the mpi-c.pc
entry point in 4.3.x (this is a regression in its own right, tracked as
#1102928). 64-bit architectures are unaffected because they use OpenMPI
instead. This can be bypassed if the libmpich-dev package either
registers a "slave" alternative for mpi-c.pc again (#1102928, #1088919),
or is rolled back to a 4.2.1+really4.3.0 version for trixie.

The other is that upstream valgrind discovers how to link MPI libraries
by using mpicc(1), which probably works with either OpenMPI or mpich,
but Debian's valgrind uses pkg-config instead as a result of a
Debian-specific patch to fix cross-compilation, originating in #902297.
(debian/patches/10_mpi-pkg-config.patch)

If mpi-c.pc is not found, 10_mpi-pkg-config.patch falls back to calling
`mpicc -showme:compile` and `mpicc -showme:link`, but those options
appear to be OpenMPI-specific. The mpich equivalents seem to be
`mpicc -show-compile-info` and `mpicc -show-link-info`.

Does mpi-defaults have a specification for what is the interoperable API
of an MPI implementation? If there's no documented spec, "the
mpi-defaults autopkgtest should pass" is probably the closest we have
(and at the moment that includes requiring a working implementation of
mpi-c.pc and mpi-fort.pc).

Perhaps as a pragmatic short-term answer to this it would be better for
10_mpi-pkg-config.patch to fall back from mpi-c.pc (which mpich doesn't
currently provide) to mpi.pc (which it still does) before
resorting to non-pkg-config mechanisms? That might result in some
overlinking (for mpich it additionally includes -lmpichfort -lpthread
-lhwloc) but that seems better than failing to build.

      smcv

+CC: stapelberg@

Assuming this is necessary for visibility :)

mpich was uploaded and valgrind now builds again on 32bit.

Here's a MR from Simon to improve the situation anyway:
https://salsa.debian.org/debian/valgrind/-/merge_requests/9

Thanks for the CC, but unfortunately I neither have time nor expertise to
look into MPI.

If the folks discussing the merge request achieve consensus, I’m happy to
merge it,
but otherwise, don’t expect anything from me on this issue. Thanks for
understanding.