NAME¶
mpicc, mpiCC / mpic++ - Compile LAM/MPI C/C++ programs.
SYNOPSIS¶
mpicc [-showme|-showme:compile|-showme:link] ...
mpiCC [-showme|-showme:compile|-showme:link] ...
mpic++ [-showme|-showme:compile|-showme:link] ...
OPTIONS¶
- -showme
- 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).
mpiCC (and therefore
mpic++) is similar, but invokes the native
C++ compiler instead.
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).
SEE ALSO¶
cc(1), CC(1),
ld(1),
lam-helpfile(5), mpif77(1)