Mk/Uses/mpi.mk: use libmpi.so in LIB_DEPENDS

[laurent]

Summary

Use libmpi.so as the base dependency library for MPICH and OpenMPI,
matching -lmpi added by MPI_LIBS.

Using libmpich.so, libmpi_cxx.so, or libmpi_mpifh.so as the dependency
library can cause false stage-qa warnings.

Also document the MPI4PY variable provided by mpi.mk.

[laurent]

thierry@, feel free to commit this yourself if you like the changes, since you are the maintainer. Or I can do it if you prefer.

[thierry]

The value of LIB_DEPENDS provided by Mk/Uses/mpi.mk only warranty that the port depends on the requested MPI port, but it does not affect how the final Makefile will catch it.

The stage-qa warnings are not always false!
This is an actual problem of our ports tree, when e.g. a port depends en OpenMPI, but one of its dependency depends on MPICH.

Mk/Uses/mpi.mk provides MPI_LIBS with (e.g. with fortran) pkgconf --libs ompi-fort, and then it is included in the final LDFLAGS.

But usually a port depends on other libraries installed under $LOCALBASE/lib, and the complete LDFLAGS will be something like:
-L$LOCALBASE/lib -llibxxx -llibyyy -L/usr/local/mpi/openmpi/lib -Wl,-rpath=-Wl,-rpath=/usr/local/lib/gcc14 -Wl,-rpath -Wl,/usr/local/mpi/openmpi/lib -Wl,--enable-new-dtags -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
and many applications are refactoring this $LDFLAGS in their Makefile.

The problem arises where libmpi exists both under -L$LOCALBASE/lib and under -L/usr/local/mpi/openmpi/lib: sometimes the linker will choose $LOCALBASE/lib/libmpi even if you requested OpenMPI, and of course this mix of libraries provided by two different implementations causes failures.

As I said you, I think that the only way to avoid this problem is to install MPICH under the default $PREFIX /usr/local/mpi/mpich, so that no libmpi.so could be found under $LOCALBASE/lib and the linker will use the correct libraries.

[laurent]

The problem arises where libmpi exists both under -L$LOCALBASE/lib and under -L/usr/local/mpi/openmpi/lib: sometimes the linker will choose $LOCALBASE/lib/libmpi even if you requested OpenMPI, and of course this mix of libraries provided by two different implementations causes failures.

I understand this point but I don't think that the current implementation is achieving what we want it to achieve because LIB_DEPENDS does not force the use of the library identified anyways, and libmpi is always linked.

As I said you, I think that the only way to avoid this problem is to install MPICH under the default $PREFIX /usr/local/mpi/mpich, so that no libmpi.so could be found under $LOCALBASE/lib and the linker will use the correct libraries.

I completely agree with this, so I will abandon this change and keep on working on the more complete change set that I'm currently testing. So far it does:

• Install mpich in /usr/local/mpi
• The change that I proposed here
• Implement a flavor framework for mpi ports

I'm hoping to open a PR this weekend for sharing the current progress and getting opinions from porters on some implementation decisions. If not this weekend, then next. I need to merge 3 branches and clean up things a bit.

[thierry]

Great! Of course it will imply an exp-run, but don't hesitate if you have some preliminary work to review.