MPI is not automatically detected on Mac OS

Create issue
Issue #1009 closed
Ian Hinder created an issue

There is logic in ExternalLibraries/MPI/configure.sh to automatically detect the location of MPI. This code looks for $X/lib/libmpi.a and $X/include/mpi.h for various values of X. This is not a robust way to locate MPI because libmpi.a is not the correct filename on Mac OS. We could make a special case for Mac OS and use ".dylib" instead of ".a", or we could remove the library file from the test, and rely on the header file alone. I prefer the latter.

Keyword:

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).

  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.

  3. Erik Schnetter
    • removed comment

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

  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.

  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)

  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.

  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.

  8. Log in to comment