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.