Package: openmpi-bin
Version: 3.1.0-7
User: [email protected]
Usertags: rebootstrap
Control: affects -1 + src:valgrind
Cross building valgrind presently fails. It detects mpi as absent and
fails the build missing files for libmpiwrap. valgrind's configure.ac
tries to link a minimal program and fails finding <mpi.h> despite
depending on mpi-default-dev. Clearly something is wrong here.
Now I think that something has something to do with openmpi-bin, but I'm
not sure what exactly. Let me make a case for filing the problem here
though.
When I run mpicc -showme after installing mpi-default-dev:arm64, I get:
gcc -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
-I/usr/lib/x86_64-linux-gnu/openmpi/include -pthread
-L/usr/lib/x86_64-linux-gnu/openmpi/lib -lmpi -lopen-rte -lopen-pal -lhwloc
-ldl -levent -levent_pthreads -lutil -lm -lrt
Clearly using x86_64 paths for arm64 sounds wrong to me. The obvious
conclusion here is that marking openmpi-bin Multi-Arch: foreign is
wrong.
The marking is well-intended however. The splitting of mpicc into a
separate binary package is a move into the right direction and having
those executables in a M-A:foreign package makes them executable at
least (as opposed to getting an Exec format error). Still it happens to
break users and thus is wrong. The simple "fix" of removing Multi-Arch:
foreign is not actually fixing anything. Things just break in a
different way.
My search for cross compiling with mpi documentation was not overly
successful. Still, some aspects have become clear to me:
* The whole concept of mpicc fundamentally breaks cross compiling.
Someone performing a cross build needs to be in charge of choosing
the compiler and mpicc removes that choice. One can still choose the
compiler via the OMPI_CC environment variable. That is if you happen
to know that your mpi implementation is openmpi. So from a cross
builders pov, /usr/bin/mpicc is very much not an interface that hides
the precise implementation. The whole idea of replacing the compiler
invocation looks fundamentally broken to me.
* mpicc offers an alternative (not recommended) way of using it:
${CC} `mpicc -showme:compile` -c $< -o $@
Going this route could be made to work, but it has a number of
caveats:
* We'd have to update every package that uses mpicc to use the
non-recommended form of invocation.
* mpicc still is not M-A:foreign, so we'd need one mpicc for each
combination of build architecture, host architecture, and mpi
implementation. With 10 architectures and 3 implementations,
that's 300 mpicc not counting ports.
* Alternatively, mpicc is somehow turned into some scripting
language such that it can be placed into the -dev package. (E.g.
the postgresql packaging does this to pg-config.)
* The whole thing looks a lot like reinventing pkg-config in a wrong
way (even though mpicc may have predated pkg-config). Indeed
libopenmpi-dev does ship e.g. ompi-c.pc and ompi-cxx.pc. Similarly
libmpich-dev ships e.g. mpich-c.pc and mpich-cxx.pc. Just lam4-dev
lacks them. So maybe an easier way could be providing alternatives
for mpi-c.pc and mpic-cxx.c and telling applications to switch to
pkg-config? It still means updating each and every application and
practically deprecating mpicc for package building, but using
pkg-config is well understood and often easy to implement.
So that's my ideas on how to make this work. Do you have more (possibly
better) ideas?
What do you think about extending the alternatives handling to the
pkg-config fils? I think the plan could be:
1. Extend lam4-dev to ship .pc files.
2. Add mpi-c.pc, mpic-cxx.pc etc.
3. Update client packages such as valgrind to use pkg-config.
This sounds like a pile of work in any case.
Helmut
