mpi.mk: use libmpi.so in LIB_DEPENDS
AbandonedPublic
Actions

Authored by laurent on Sun, May 17, 7:52 PM.

Details

Reviewers

thierry

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.

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 73171
Build 70054: arc lint + arc unit

Event Timeline

laurent requested review of this revision.Sun, May 17, 7:52 PM

laurent created this revision.

Harbormaster completed remote builds in B73171: Diff 177982.Sun, May 17, 7:52 PM

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.

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.

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.

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

Revision Contents
Changeset List

Path

Size

Mk/

Uses/

mpi.mk

8 lines

Diff 177982

View Options

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