+CC: stapelberg@ Assuming this is necessary for visibility :)
On Fri, Apr 25, 2025 at 01:36:17PM +0100, Simon McVittie wrote: > 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
