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)

LAM 7.1.4                                          July, 2007                                           mpicc(1)