mpiCC.lam - Online in the Cloud

PROGRAM:

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

Use mpiCC.lam online using onworks.net services