On Wed, 23 Apr 2025 at 10:26:03 +0100, Simon McVittie wrote:
While checking why the fix for #1057621 wasn't migrating to testing, I
noticed that the updated valgrind has failed to build on [32-bit]
...
I see that valgrind's configure check for mpi-c is failing:
checking for mpicc... /usr/bin/mpicc
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for mpi-c... no
gcc: error: unrecognized command-line option '-showme:compile'
gcc: error: unrecognized command-line option '-showme:link'
checking primary target for usable MPI2-compliant C compiler and mpi.h... no
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
