Page MenuHomeFreeBSD

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

Authored by laurent on Sun, May 17, 7:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, May 25, 1:44 AM
Unknown Object (File)
Sun, May 24, 4:27 PM
Unknown Object (File)
Sat, May 23, 10:59 PM
Unknown Object (File)
Thu, May 21, 5:55 PM
Unknown Object (File)
Thu, May 21, 9:26 AM
Unknown Object (File)
Wed, May 20, 8:09 PM
Unknown Object (File)
Tue, May 19, 4:18 AM
Unknown Object (File)
Mon, May 18, 2:54 AM
Subscribers
None

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 created this revision.

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.