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)