Re: Open MPI keeps references to GCC, GFortran, etc.

[Dave Love]

Ludovic Courtès <address@hidden> writes:

> Hello,
>
> Open MPI retains references to GCC, GFortran, etc., which significantly
> increases its closure size.

My query about cycles from separating the lib output was from looking at
basically this.  There should be a runtime package for compute nodes and
a development one (as "openmpi" and "openmpi-devel" in Fedora).

[It's not the only example of monstrous dependencies I've noticed
trying to build things.]

> The references come from cpp macros such as OMPI_FC_ABSOLUTE (absolute
> file name of the Fortran compiler), defined in opal_config.h and
> returned by command-line tools ‘ompi_info’ and ‘oshmem_info’.

I'm confused what the wrappers are doing, and would have to dig into the
code to find out.  "strings" on a version on our cluster doesn't actually
show gfortran, and "mpifort -showme" doesn't have a path name for it.  I
think I've been here before, but have forgotten.

> What would be the impact of changing these OMPI_*_ABSOLUTE uses to just
> the basename of the compiler?  Are there tools or practices that rely on
> the info provided by these two commands?

There should be no dependence on the C compiler.  I can't say about C++,
past the standard library version, but I think it's deprecated anyhow.
Apart from minor ABI incompatibilities, as far as I know (and when they
change the libfortran soname, sigh), the dependence on a specific
version of gfortran is down to the highly annoying backwards
incompatibility of the module file formats (e.g. mpi.mod).  You can
change the compiler at runtime with an environment variable (OMPI_FC
(?)) and it will either work or fail according to the version of .mod
files involved.  It's annoying that the only real difference between
painstakingly-built mpi packages for different gfortran versions is the
.mod files.

There are plenty of things which don't just use the compiler wrappers as
they should and, I think some try their "-showme" options to get
information.  I can't immediately think of which do, and how, but I can
have a look around at things I have packaged.  I doubt it's worth
worrying about, though.

I was intending to look at parameterizing the build on gfortran version,
which is basically a case of setting "FC" appropriately for configure
(possibly rebuilding just the Fortran part for a list of FCs within one
package build, and installing the module files in different places,
which I've never got round to looking at with rpm).  I'm not clear how
dependencies are, or should be, propagated for different compilers, but
guess it will be trivial.  To support multiple gfortran versions, this
also needs doing for the development part of any library packages that
provide Fortran modules.  [I can rant at length on the combinatorial
build explosion that typically infects HPC installations.  That's part
of the interest in Guix, and I was initially looking at improving MPI
stuff as something I understand from Fedora-land.]

Should I carry on looking at separating out and parameterizing parts of
openmpi, or will a Guix expert work on it?  I'm currently stuck with
figuring out the cycle from the build, but haven't put much effort into
it, and it's not as simple as just turning on the "lib" output.

I don't know whether that helps much, but I can probably answer
questions on anything I might know more about than others.