On 20/06/2018 21:33, Helmut Grohne wrote:
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.
Just to note: While I believe mpicc* should be deprecated, this is not
yet accepted / discussed much in the community at large.
I think we should push this issue and the use of pkg-config.
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.
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. ...
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.
Sorry, I don't understand.
my thinking is that we need to move mpicc-wrapper-data.txt from
/usr/share to a M-A-aware location,
and make mpicc search the right path.
My question is: what is the canonical method we specify for determining
the target architecture of a build?
using pkg-config (which i've done for other packages, eg ADIOS which
ships adios-config, etc.) inherits the answer from pkg-config
(which I presume uses PKG_CONFIG_PATH over the default value of
/usr/lib/pkg-config.multiarch)
If I have multiple architecture versions of libopenmpi-dev installed,
how is a cross-build expected to choose the right paths? this is
important for e.g. cmake as well as pkg-config.
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
I've been effectively doing this. OpenMPI ships ompi-c, ompi-cxx,
ompi-fort; I've added mpich-c, mpich-cxx, mpich-fort.
and mpi-c, mpi-cxx, mpi-fort are (alternatives-based) symlinks to these.
I haven't yet extended this to LAM, as its unclear to me whether LAM
should / will be removed from Buster, as it is
dead upstream (I'm in contact with the maintainer on this ATM).
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
Alastair
--
Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.
