mpicc

NAME

mpicc, mpiCC - Compile LAM/MPI C/C++ programs.

SYNTAX

mpicc [-showme] ...

mpiCC [-showme] ...

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.

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

DESCRIPTION

mpicc and mpiCC 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 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 no compelling reasons not to use mpicc/mpiCC.

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 LAMHCC environment variable.

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 LAMHCP environment variable.

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 hcc and hcp did not automatically link in the MPI library. Starting with LAM version 6.3, since hcc and hcp have become the de facto LAM C and C++ compilers, the -lmpi option is now automatically passed to the underlying compiler when linking LAM/MPI programs. As such, the names hcc and hcp are deprecated; the use of the names mpicc and mpiCC are now encouraged.

Previous versions of LAM included the mpicc and mpiCC wrapper scripts to automatically pass -lmpi to hcc and/or hcp. These scripts are now obsolete since hcc and hcp now include -lmpi automatically. mpicc and mpiCC are now symbolic links to hcc and hcp, respectively, to ensure backward compatibility.