SYNTAX

OPTIONS

Does not invoke the underlying C/C++ compiler. Instead, it shows the
command line that would be executed to compile the C/C++ program.

-showme:compile

Does not invoke the underlying C/C++ compiler. Instead, it shows
the compiler flags that would be supplied to the C/C++ compiler.

-showme:link

Does not invoke the underlying C/C++ compiler. Instead, it shows
the linker flags that would be supplied to the C/C++ compiler.

See cc(1) and CC(1) (or whatever your underlying C/C++ compilers are)
for all other options.

DESCRIPTION

mpicc
and
mpiCC
(mpic++
is a synonym for
mpiCC
provided for filenames that do not support case-sensitive filenames)
are convenience wrappers for the local native C and C++ compilers.
Translation of a LAM program requires the linkage of the LAM specific
libraries which may not reside in one of the standard search
directories of ld(1). It also often requires the inclusion of header
files what may also not be found in a standard location.
mpicc
passes its arguments to the local native C compiler along with the -I,
-L and -l options required by LAM programs. This includes all
necessary options for ROMIO and/or C++ bindings support (if ROMIO/C++
support was included when LAM was compiled).

The LAM Team
strongly
encourages using
mpicc
and
mpiCC
instead of attempting to link to the LAM libraries manually. This
allows the specific implementation of LAM to change without forcing
changes to linker directives in users' Makefiles (the specific set of
underlying LAM libraries has already changed multiple times, and will
likely change again in future versions).

Indeed, since
mpicc/mpiCC
are very thin wrappers on top of an underlying compiler, there are
very, very few compelling reasons
not
to use
mpicc/mpiCC.
When it is not possible to use
mpicc/mpiCC,
the
-showme:compile
and
-showme:link
arguments should be used instead. For example:

shell$ cc -c file1.c `mpicc -showme:compile`

shell$ cc -c file2.c `mpicc -showme:compile`

shell$ cc file1.o file2.o `mpicc -showme:link` -o my_mpi_program

ENVIRONMENT VARIABLES

By default,
mpicc
uses the C compiler that was selected when LAM was configured (with
the --with-cc flag to ./configure, or by setting the environment
variable CC before ./configure was invoked) as the local native C
compiler, but this can be overridden by the LAMMPICC environment
variable (an older name for this environment variable is LAMHCC --
this also still works, but its use is deprecated).

Likewise,
mpiCC
uses the C++ compiler that was selected when LAM was configured (with
the --with-cpp flag to ./configure, or by setting the environment
variable CXX before invoking ./configure) by default, but this can be
overridden by the LAMMPICXX environment variable (an older name for
this environment variable is LAMHCP -- this also still works, but its
use is deprecated).

If the environment variable
LAMHOME
is set,
mpicc
and
mpiCC
will use its value as the location of the LAM installation directory
instead of the value that was compiled into
mpicc/mpiCC.
This means that
mpicc/mpiCC
will use the value of
LAMHOME
as the base to create the -I and -L arguments that are passed to the
lower-level compiler, not the installation directory that was supplied
when
mpicc/mpiCC
were created. This is almost always a Bad Idea.

The use of
LAMHOME
is discouraged except for some rare configuration cases in oddly
networked sites (in which case your system administrator should
probably set this up), and for advanced users with multiple LAM/MPI
installations who really know what they are doing; if the
LAMHOME
environment variable is unintentionally left set, it can lead to
tremendous user confusion. For example, if
LAMHOME
points to LAM installation A, but the user's
PATH
points to LAM installation B, then even though B's
mpicc
will be used, the user program will be compiled and linked against LAM
installation A.

The
LAMHOME
environment variable is mainly only left in place for backwards
compatibility; it is not required for normal functioning of LAM/MPI.
The LAM Team discourages the use of the
LAMHOME
environment variable, and instead advocates simply setting the
PATH
properly to switch between multiple LAM/MPI implementations.

NOTES

Previous versions of LAM encouraged the use of
hcc
and
hcp
to compile LAM and/or MPI C and C++ applications, respectively. In
very old versions of LAM,
hcc
and
hcp
did not automatically add
-lmpi
to the command line.
hcc
and
hcp
were eventually deprecated and replaced with
mpicc
and
mpiCC
(or
mpic++
on case-insensitive filesystems). The executables
hcc
and
hcp
are now simply symbolic links to
mpicc
and
mpic++,
respectively, just in case there's anyone out there that still uses
those names. It should be harmless to pass in the additional
-lmpi;
mpicc
and
mpic++
should silently do the Right Thing (only link in the MPI library once).