Re: Bug#1103970: valgrind: FTBFS on 32-bit: Cannot find (any matches for) "usr/lib/*/valgrind/libmpiwrap*"

+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