[lammps-users] FYI: MPI stub and compilation issues on the mac.

Hi All,

I don't know if anyone else has commented on this. I have had tremendous difficulty in compiling lamps on a mac (intel cpu with Leopard). I was finally successful when I stopped trying to use the MPI stub that comes with the program. I am fairly certain it was the stub that was causing the issues as the make file was pointing to ../STUBS. The compilation that was successful was using fink's openmpi and fftw options. Why this should work and the mpi stub not, I have no idea.

If anyone using a mac with fink would like my make file please let me know.

matthew

hi matthew,

Hi All,

I don't know if anyone else has commented on this. I have had tremendous difficulty in compiling lamps on a mac (intel cpu with Leopard). I was finally successful when I stopped trying to use the MPI stub that comes with the program. I am fairly certain it was the stub that was causing the issues as the make file was pointing to ../STUBS. The compilation that was successful was using fink's openmpi and fftw options. Why this should work and the mpi stub not, I have no idea.

the MPI stub code is extremely simple and very portable.
it is much more likely that something else went wrong and
you just avoided the issue.

can you please send the error messages that you were getting?

If anyone using a mac with fink would like my make file please let me know.

i would rather want to see the makefile settings that didn't work.

thanks,
    axel.

This is a problem that I have also encountered, and the workaround is very simple. In MAKE/Makefile.serial make the following change:

#Comment out this
#MPI_LIB = -lmpi
#Add this
MPI_LIB = …/STUBS/libmpi.a

The more difficult question is: “why does this work?” The answer is (I know this empirically), when the GNU compiler searches for the library requested by -lmpi,
it first searches for:

libmpi.dylib

It will use it instead of the one specified by the user using -L. This seems to completely conflict with how libraries are supposed to be searched, but that’s how it is. I have this library installed in /usr/local/lib from Open MPI, and another in /usr/lib from I don’t know where. So rather than try to tell the compiler not to use them, I just link the entire STUBS/libmpi.a, which is fine, because it is tiny.

This is a problem that I have also encountered, and the workaround is
very simple. In MAKE/Makefile.serial make the following change:

#Comment out this
#MPI_LIB = -lmpi
#Add this
MPI_LIB = ../STUBS/libmpi.a

The more difficult question is: "why does this work?" The answer is
(I know this empirically), when the GNU compiler searches for the
library requested by -lmpi,
it first searches for:

libmpi.dylib

this is actually not an issue of the compiler, but of the linker.
and strictly speaking it is not the GNU linker directly, but the
hacks that apple programmers applied to it. for some reason, probably
due to paranoia, they were not satisfied with the "normal" way of
how libraries are resolved and they implemented something different
mechanism that prefers system libraries over self-compiled ones.

It will use it instead of the one specified by the user using -L. This
seems to completely conflict with how libraries are supposed to be
searched, but that's how it is. I have this library installed

if you want to see even weirder, have a look at how AIX handles
shared vs. static libraries (or better not). ... or linux shared
librararies in a.out format way back when.

in /usr/local/lib from Open MPI, and another in /usr/lib from I don't
know where. So rather than try to tell the compiler not to use them, I
just link the entire STUBS/libmpi.a,
which is fine, because it is tiny.

actually, the effect of linking a (static = .a) library via
-L<path> -l<name> versus using <path>/lib<name>.a is exactly
the same. only the text and data segments from object providing
unresolved symbols and their prerequisites will be copied into
the final executable. the -l<name> notation is mainly for convenience.

now, with dynamical libraries the situation is different
and more operating system and compiler/linker version specific.

cheers,
   axel.

Axel, thanks for additional insight into this annoying Apple feature. Given that there is no downside, maybe we should use

MPI_LIB = …/STUBS/libmpi.a

for all Makefile.serial variants. Are then any platforms/compilers/linkers where this won’t work?

none that i know of. some linkers may be more sensitive to
having the correct linking order with this approach, but in this
case this is a non-issue (no other library that would be "later"
in the linking order should require MPI symbols).

cheers,
    axel.