MPI is not automatically detected on Mac OS

Comments (9)

1. 

   Roland Haas

   • removed comment

   Also mpich calls its library libmpich (which is not checked for). There configure.sh scripts are getting out of hand it seems. Maybe we should consider actually making them configure (as in autoconf) scripts and provide a set of Cactus .m4 macros (which I kind of dread since the .m4 syntax is so unusual compared to anything but TeX).

   • 2012-08-03T11:33:20+00:00
2. 

   Ian Hinder reporter

   • removed comment

   There is a large amount of historical logic in the old extras mechanism for locating MPI libraries. All of this has been lost when converting to the new thorn. This may or may not be a good thing.

   I agree that the configure scripts have gotten out of hand. We have duplicated logic across most of them which should be factored out and provided by Cactus at the very least.

   • 2012-08-03T11:39:41+00:00
3. 

   Erik Schnetter

   • removed comment

   Other external libraries already have logic that accept either .a, .so, or .dylib as library extensions.

   • 2012-08-03T12:22:42+00:00
4. 

   Frank Löffler

   • removed comment

   This is a bit more complicated. Because of the possibility of having multiple different installations of mpi versions being installed at the same time, the header files can end up in totally different places than the libraries and are not nicely predictable. Once example is /usr/lib64/mpich2/lib/libmpich.so and /usr/include/mpich2-x86_64/mpi.h, or /usr/lib64/openmpi/lib/libmpi.so and /usr/include/openmpi-x86_64/mpi.h.

   One would have to - search for the libraries/utilities (reasonable) - use these tools to obtain the include paths, e.g. openmpi/bin/mpicc --show - parse the output and use these while building.

   All this would not be necessary if the mpicc ect. wrappers would be used, but they often cannot because of the wish to use another compiler than the mpi libraries have been built with.

   • 2012-08-09T15:01:11+00:00
5. 

   Frank Löffler

   • removed comment

   We could make this work a bit nicer if MPI would do something along the lines of

   for libext in a so dylib; do
     for deepdir1 in "." openmpi; do
       for deepdir2 in "." openmpi; do
         for libdir in lib64 lib; do # and a couple more here that I left out
           FILES="$deepdir1/include/$deepdir2/mpi.h $deepdir1/$libdir/$deepdir2/libmpi.${libext}"
   

   (Not proposing a patch now because of a lack of time)

   • 2013-02-14T09:19:53+00:00
6. 

   Roland Haas

   • removed comment

   Is this still an issue? Similarly it would be useful if MPI were to detect MPI stacks other than OpenMPI so that eg ubuntu.cfg from simfactory could lose its MPI_DIR option and could be used for both mpich2 (Ubuntu default) and OpenMPI (what many actually use).

   It is somewhat annoying having a new (or not so new) user have to recompile everything from scratch since they have the "wrong" MPI installed.

   • 2013-10-30T20:03:50+00:00
7. 

   Ian Hinder reporter

   • removed comment

   This commit, http://git.barrywardell.net/?p=arrangements/ExternalLibraries/MPI.git;a=commit;h=b13c2160b32e0ccbfeea9812f8d3db7d5e2fce50, looks like it was intended to fix the problem. I just tried building a configuration with just ExternalLibraries/MPI in the thornlist and an empty optionlist, and MPI from macports was detected correctly. This addresses this ticket, so I am closing it. Feel free to open a new ticket requesting that the MPI detection logic be enhanced to detect other MPI packages.

   • 2013-11-05T08:06:19+00:00
8. 

   Ian Hinder reporter

   • changed status to resolved
   • removed comment

   • 2013-11-05T08:06:28+00:00
9. 

   Roland Haas

   • edited description
   • changed status to closed

   • 2019-02-21T19:53:31+00:00
10. Log in to comment