On Wed, Jun 20, 2018 at 07:19:01AM +0100, Alastair McKinstry wrote:
> As the person responsible for this to date in openmpi / mpich, my thinking
> is this:
> (1) mpicc, etc. wrappers should be deprecated*, but are widespread amongst
> the community.
I'm very relieved by that statement. No, it will not happen quickly, but
that paves the road for deploying proper fixes without carrying
non-upstreamable patches indefinitely.
> They can be made to pull the data from pkg-config (or cmake equivalent)
> files.
I'm not sure that making mpicc pull data out of pkg-config is useful. If
it makes your work easier, then that's fine. Still I don't think it
helps cross compilation in any way. pkg-config works well with cross
compilation, because it is commonly called as <triplet>-pkg-config and
thus knows which architecture you mean. mpicc however is not commonly
called as <triplet>-mpicc and thus does not have that knowledge. It will
not be able to tell which <triplet>-pkg-config to call. Thus making
mpicc use pkg-config will not magically fix cross compilation.
Making upstreams switch from mpicc to calling pkg-config directly will
fix this.
> mpicc.openmpi pulls its data from /usr/share/openmpi/mpicc-wrapper-data.txt
> . This needs to be moved into a multiarch
> directory, and the binary pull the correct one according to architecture
> ($(DEB_BUILD_MULTIARCH)).
It's not that easy unfortunately. I might agree that
mpicc-wrapper-data.txt could live in a multiarch location. Using
DEB_BUILD_MULTIARCH is entirely wrong though. The variable describes the
architecture you are building on, not the one you are building for. You
likely meant "host" here (see man dpkg-architecture). Then relying on
DEB_* environment variables is bad. It will work for package builds, but
people will want to use mpicc for doing other things than package
building. So unless you want to break people running mpicc outside
package builds, you cannot use DEB_* variables at all.
Let me try to turn this into a better draft though. If you need mpicc,
you cannot reasonably expect it to work for two architectures at the
same time (how should it tell which one you mean?). So if we remove the
M-A:same from libopenmpi-dev, we can move mpicc-wrapper-data.txt to
libopenmpi-dev *without* moving it to a multiarch location. (Note that
having it on /usr/share is conceptually wrong in any case as the content
is architecture-dependent.) Not being m-a:same sounds bad and it kinda
is, but in reality, we rarely need -dev packages to be M-A:same. For
instance, libgpg-error-dev is not M-A:same, can't be and that's mostly
fine. Now after installing libopenmpi-dev:arm64, it'll pull the native
openmpi-bin (e.g. :amd64), which will read the mpicc-wrapper-data.txt
from the arm64 package and output the right values! That alone should be
enough to fix valgrind.
If you implement that, please close this bug.
> (3) Yes, its work. Splitting mpi for m-a has been.
I know and I'm willing to help here.
> (*) There are a bunch of places where the *-config / mpicc type wrapper
> scripts have been used. See e.g. h5cc ,etc within HDF5, which abstracts the
> necessary compile environment.
> This is ok if its just mpi, but then h5cc wraps mpicc or cc, and you have
> other layers like adios wrapping on top of h5cc, etc.
> You end up with a 'wrapper war' where everyone wants to be on top, and you
> can't easily combine complex libraries.
> pkgconfig allows for composition, and abstraction much better.
That sounds like moving to pkg-config solves many problems.
> pkg-config should now work for the openmpi / mpich case, and I think we
> should push patches to use pkg-config rather than mpicc
> back to upstream.
If pkg-config is the way to go, I wonder how downstreams should search
for mpi. Should they ask for particular implementations in their order
of preference? E.g.
for mpi in ompi-c mpich-c; do pkg-config --exists $mpi && echo $mpi &&
break; done
Should we provide some alternative such as "mpi-c.pc" suggested in my
initial mail? Should the builder explicitly have to supply the
implementation? E.g. --with-mpi=ompi
To me it is very much unclear how one is supposed to use the pkg-config
interface to mpi due to its multiple implementations. Once I know, I'm
happy to send a patch that makes valgrind (and others) use that.
Helmut
