Configuring with --disable-mpi-fortran still installs mpifort(1)

[jsquyres]

@dalcinl noticed that if you configure with --disable-mpi-fortran, we still install mpifort (and sym-linked friends, such as mpif90). This seems incorrect, especially since they include -lmpi_mpifh, and libmpi_mpifh does not exist (i.e., is not installed).

I observed this on the v4.1 branch, but it's probably in v4.0, master, and v5.0 as well.

@ggouaillardet Can you think of any reason that we would want to install mpifort (etc.) when there are no Fortran bindings? I can't think of any -- I'd just like to check to make sure that there's no dark, subtle reason we're doing this...

[ggouaillardet]

@jsquyres that sounds like a bug.

There is a good reason for installing C++ wrappers even when C++ bindings are not built, but I cannot remember a good rationale for doing it with Fortran.

[dalcinl]

Well, if MPI had an ABI, we could be using MPI via ISO_C_BINDINGS.

On a more everyday situation, imagine that you have some app written in both C and Fortran. The C code makes MPI calls, but the Fortran code is all sequential, no MPI. At some point you have to link your object files. Some folks will likely prefer to do the linking via Fortran. So it makes sense to use mpifort, even if no Fortran MPI is involved. Of course, mpifort should link in just the plain "C" MPI library, because the Fortran MPI library is not available.

So, in short, perhaps it is still a good idea to install mpifort.

However, take a look here:

$ mpifort -show
gfortran -I<prefix>/include -Wl,-rpath -Wl,<prefix>/lib -L<prefix>/lib -lmpi_mpifh -lmpi

The -lmpi_mpifh is obviously wrong, this compiler wrapper line is broken.

EDIT: Of course, the mpifort -show output above is from a --disable-mpi-fortran build.

[jsquyres]

That may well be the reason we're still installing mpifort and friends (to link an overall C+Fortran MPI application).

I don't think I have a strong opinion here; I believe that going either way will not be a big fix (i.e., either removing fortran libraries from the Fortran wrapper compiler link lines, or not installing mpifort at all).

[bosilca]

I like @dalcinl idea because it is a very normal scenario for many HPC applications, and today's solution (aka. finding the correct include/link options to make it work) is a major hassle.

[jsquyres]

@bosilca Thanks -- I was going to raise this issue for larger visibility, but since at least one other person chimed in, I'm happy to accept that solution (i.e., let's remove the MPI Fortran libs and make mpifort still be safe to use).

FWIW: this has been broken since at least 4.0.0 (I didn't test earlier than that). So this hasn't worked in a long time.

[hjelmn]

I vote for not installing it at all if --disable-mpi-fortran. I run a fortran-free system and ompi-tests makes some assumptions if it sees mpifort at all.

[dalcinl]

@hjelmn Wouldn't it be better to update ompi-tests assumptions? Is that really hard?

@jsquyres Alternatively, perhaps you need an extra configure flag --disable-fortran that will skip absolutely everything Fortran-related (bindings, wrappers, the stuff ompi_info prints, etc)? This way you accommodate for @hjelmn user case. And now that I'm at it, because asking is free and you do the work, why not --disable-cxx?

[jsquyres]

I vote for not installing it at all if --disable-mpi-fortran. I run a fortran-free system and ompi-tests makes some assumptions if it sees mpifort at all.

If that were true, then you wouldn't have been able to build/run ompi-tests on your Fortran-free system for years... 😉