When building math/octave, it pulls in math/arpack-ng. math/arpack-ng unilaterally uses net/mpich for the MPI implementation. That is, it does not use net/openmpi when a user specifically requests OpenMPI.
I have been thinking about DEFAULT_MPI for a long time, but it does not exists ATM. It seems that most of the ports in the tree using MPI could be built against any of them, and I thought about introducing a flavor, so that the packages would be built against the two implementations, but this is just a project. One problem: if MPICH has been installed on a machine, many ports trying to link against OpenMPI will in fact catch libmpi from MPICH, because it is located under $LOCALBASE/lib. Therefore it would be safer to install only one implementation, and have all the installed ports or packages depend on it. We just need time to do it.
(In reply to Thierry Thomas from comment #1) Interesting. I have DEFAULT_MPI=openmpi in my /etc/make.conf. I don't remember adding it and there's no comment. Yes, there can be conflicts if one installs both openmpi and mpich. I tested both years ago, and openmpi significantly out performed mpich on my benchmarks. So, I've used openmpi ever since. With the arpack-ng port, I simply edit the Makefile and plist to eliminate the MPICH dependence. The shared libraries are certainly going to be a problem. Whichever libmpi.so.XXX appears first in ldconfig's cache will win. Static libraries are less problematic, but a user would need to use, e.g., -L/usr/local/mpi/openmpi/lib. If you want to close the bug report, feel free to do so.
Maybe it could be interesting to keep a PR, since there is a real problem, but just change its object? Also CC'ing Laurent, maintainer of the MPI ports.
Ok, I changed the title. If you have a better, feel free to change. In the short term, may be a menu option to disable the use of mpich can be added. I'm not sure how to implement this. I look through other Makefiles to see if I can develop a patch.
Sorry in advance for the long reply. If you require an immediate solution, I can help you create an openmpi flavor of math/arpack-ng. If there is a little time, I'd like to propose the following long term solution. It is based on past conversations with Thierry and others. Consider this as a basis for discussion, not a final roadmap. Please feel free to point out issues (and hopefully also solutions) with what I am proposing. The problem is that the MPI implementation is currently only a build choice, not part of the package identity. As a result, a final binary can end up linking libraries built against different MPI implementations, which is not safe. A long-term fix would be to make MPI a framework-managed flavor for ports that install MPI dependent libraries. A port using: USES=mpi:flavors would cause mpi.mk to define the MPI flavor set automatically and assign distinct package suffixes such as -mpich and -openmpi. For example, mpi.mk could define: FLAVORS= mpich openmpi PKGNAMESUFFIX= -${FLAVOR} MPI_PORT_SUFFIX= @${FLAVOR} With the proposed mechanism, math/arpack-ng could use: USES=mpi:flavors This would produce the following packages: math/arpack-ng-mpich math/arpack-ng-openmpi Then math/octave could depend on: LIB_DEPENDS= libarpack.so:math/arpack-ng@openmpi to pull in the openmpi variant of math/arpack-ng instead of the MPICH one. math/octave could also easily support both MPI implementations by adding: USES=mpi:flavors LIB_DEPENDS= libarpack.so:math/arpack-ng${MPI_PORT_SUFFIX} This way users could chose which version of MPI they prefer to use (maybe they have a modified MPI library that they prefer to build with, or one supports theyr hardware better than the other, etc.) This mechanism can be introduced gradually. Ports can migrate one by one to USES=mpi:flavors without requiring a tree-wide conversion. Ports that have not yet been converted would continue to behave exactly as they do today. I could add documentation in the porter's andbook as well to make it clear how to use the MPI framework properly.
(In reply to Laurent Chardon from comment #5) Your suggested long term solution looks good to me. A short term solution would be to add a built option to completely disable the use of MPI. I don't know the internals of the port/Mk system, so cannot quickly whip up the needed 'OPTION_DEFINE= MPICH', but the following works for me to disable MPICH. diff --git a/math/arpack-ng/Makefile b/math/arpack-ng/Makefile index 76ccea6597fe..914575eb8b0e 100644 --- a/math/arpack-ng/Makefile +++ b/math/arpack-ng/Makefile @@ -10,17 +10,20 @@ WWW= https://forge.scilab.org/index.php/p/arpack-ng/ LICENSE= BSD3CLAUSE LICENSE_FILE= ${WRKSRC}/COPYING -LIB_DEPENDS= libmpich.so:net/mpich # MPI is incremental: it adds the libparpack.so lib, it is a candidate for a sub-package - USES= autoreconf fortran libtool localbase pkgconfig USE_GITHUB= yes GH_ACCOUNT= opencollab GNU_CONFIGURE= yes CONFIGURE_ARGS= --with-blas="${BLASLIB}" \ --with-lapack="${LAPACKLIB}" \ - --enable-mpi \ --disable-static \ --enable-icb + +.ifdef MPICH +CONFIGURE_ARGS+= --enable-mpi +LIB_DEPENDS= libmpich.so:net/mpich # MPI is incremental: it adds the libparpack.so lib, it is a candidate for a sub-package +.endif + TEST_TARGET= check USE_LDCONFIG= yes @@ -41,9 +44,15 @@ NETLIB_USES= blaslapack:netlib OPENBLAS_USES= blaslapack:openblas pre-configure: +.ifdef MPICH + @cat pkg-plist-none pkg-plist-mpich > pkg-plist +.else + @cp pkg-plist-none pkg-plist +.endif cd ${WRKSRC} && ./bootstrap post-install: + @rm -f pkg-plist @${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib*arpack.so.*.* post-install-DOCS-on: diff --git a/math/arpack-ng/pkg-plist b/math/arpack-ng/pkg-plist deleted file mode 100644 index 4e566a75cdbe..000000000000 --- a/math/arpack-ng/pkg-plist +++ /dev/null @@ -1,22 +0,0 @@ -include/arpack/arpack.h -include/arpack/arpack.hpp -include/arpack/arpackdef.h -include/arpack/arpackicb.h -include/arpack/debug.h -include/arpack/debugF90.h -include/arpack/debug_c.h -include/arpack/debug_c.hpp -include/arpack/parpack.h -include/arpack/parpack.hpp -include/arpack/stat.h -include/arpack/statF90.h -include/arpack/stat_c.h -include/arpack/stat_c.hpp -lib/libarpack.so -lib/libarpack.so.2 -lib/libarpack.so.2.1.0 -lib/libparpack.so -lib/libparpack.so.2 -lib/libparpack.so.2.1.0 -libdata/pkgconfig/arpack.pc -libdata/pkgconfig/parpack.pc diff --git a/arpack-ng/pkg-plist-none b/arpack-ng/pkg-plist-none new file mode 100644 index 0000000..dd035ba --- /dev/null +++ b/arpack-ng/pkg-plist-none @@ -0,0 +1,16 @@ +include/arpack/arpack.h +include/arpack/arpack.hpp +include/arpack/arpackdef.h +include/arpack/arpackicb.h +include/arpack/debug.h +include/arpack/debugF90.h +include/arpack/debug_c.h +include/arpack/debug_c.hpp +include/arpack/stat.h +include/arpack/statF90.h +include/arpack/stat_c.h +include/arpack/stat_c.hpp +lib/libarpack.so +lib/libarpack.so.2 +lib/libarpack.so.2.1.0 +libdata/pkgconfig/arpack.pc diff --git a/arpack-ng/pkg-plist-mpich b/arpack-ng/pkg-plist-mpich new file mode 100644 index 0000000..c843a94 --- /dev/null +++ b/arpack-ng/pkg-plist-mpich @@ -0,0 +1,6 @@ +include/arpack/parpack.h +include/arpack/parpack.hpp +lib/libparpack.so +lib/libparpack.so.2 +lib/libparpack.so.2.1.0 +libdata/pkgconfig/parpack.pc