Control: affects -1 - src:valgrind
On Fri, Jun 22, 2018 at 10:22:41AM +0100, Alastair McKinstry wrote:
> 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.
Ok.
> 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.
That's one possible method and it is the one chosen by pkg-config, but
there is another method chosen e.g. by gpg-error-config:
Make the -dev package M-A:no. Then mpicc can only be installed for a
single architecture and it'll report the flags for whatever architecture
it was installed for. This sounds like a regression as libopenmpi-dev
cannot be M-A:same, but it practically gets us quite far. The intuition
that everything needs to be Multi-Arch is wrong.
> My question is: what is the canonical method we specify for determining the
> target architecture of a build?
The canonical method is prefixing architecture-dependent tools with the
host gnu triplet (${DEB_HOST_GNU_TYPE}-${TOOL}).
> 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)
For pkg-config, we have wrappers <triplet>-pkg-config that set up
PKG_CONFIG_LIBDIR before calling the real pkg-config binary. It is the
responsibility of the client package to choose the right pkg-config
executable. Updating packages to prefer <triplet>-pkg-config over
pkg-config is a significant fraction of patches I sent. Note that this
approach is not Debian-specific. This prefixing is quite universal and
benefits other distributions as well as the gnu triplet is quite
universal across distributions.
Note that adios-config will simply not work for cross, because it calls
the unprefixed pkg-config. A number of such wrappers have the same
problem and the solution is to not use the wrapper.
Setting up PKG_CONFIG_LIBDIR ahead of the build would be wrong, because
sometimes you need to use pkg-config for the build architecture. If we'd
supply a PKG_CONFIG_LIBDIR, that would simply not work at all.
> 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.
For pkg-config this problem is mostly solved by popularity. It ships an
autoconf macro PKG_PROG_PKG_CONFIG (which prefers the triplet path).
Some people still use AC_PATH_PROG([PKG_CONFIG],[pkg-config]), but I'm
patching those away. For cmake, dh_auto_configure supplies the
configuration via flags and those flags include PKG_CONFIG_EXECUTABLE.
For qmake the situation is quite similar except that we ended up adding
a <triplet>-qmake wrapper (like for pkg-config) that comes up with all
the flags before calling the real qmake. The value of the qmake wrapper
comes from dh_auto_configure calling it. So in essence, we fixed each
build system once for making pkg-config work and now ask everyone else
to use pkg-config.
So you have a choice here:
A. Ship <triplet>-mpicc and make everyone use AC_PATH_TOOL over
AC_PATH_PROG.
B. Make libopenmpi-dev Multi-Arch: no and let mpicc operate for whatever
architecture it was installed for.
C. Ignore the problem and move to pkg-config directly.
I think that A entails updating every single mpicc client. At that
point, we can do C with equal effort.
I'm not sure whether B is worth the effort and it is a temporary
solution at best. The long term plan seems to be C. So we might want to
skip B entirely.
You can also go a mixture of A and B:
D. Ship *only* <triplet>-mpicc in libopenmpi-dev and move the
/usr/bin/mpicc alternative to a new package libopenmpi-legacy-dev,
which is M-A:no. This still incurs updating all rdeps, but this time
it suddenly causes a FTBFS and the simple fix is updating
Build-Depends.
> 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.
Wow. I didn't realize that this is fully implemented already. So there
is nothing left to do on the openmpi side for switching downstreams from
mpicc to pkg-config! Do I need some kind of minimum version to use
mpi-c.pc?
I'll look into supplying a patch for valgrind to move it to pkg-config.
> 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).
Fair enough.
I see that you've done a lot of effort on these matters and you've moved
us forward quite a bit. Thank you!
Helmut
