mpicc(1)

💅 mpicc — LAM TOOLS era, bestie

okay so real talk: this is the manual page for mpicc, mpiCC and mpic++, the lil compiler wrappers that live in the LAM TOOLS section of your man pages. grab a snack, we're gonna get you compiling MPI programs like it's nothing. ✨

---

🌸 NAME 🌸

mpicc, mpiCC / mpic++ — compile LAM/MPI C/C++ programs. that's the whole job description, and they ate. 💖

---

🎀 SYNOPSIS 🎀

mpicc [-showme|-showme:compile|-showme:link] ...

mpiCC [-showme|-showme:compile|-showme:link] ...

mpic++ [-showme|-showme:compile|-showme:link] ...

like, same energy, three different names. pick your fighter. 🦋

---

✨ OPTIONS ✨

• -showme — does NOT actually run the underlying C/C++ compiler. instead it just shows you the command line that would have been executed to compile your C/C++ program. it's giving "peek behind the curtain" 🔍
• -showme:compile — also doesn't invoke the underlying C/C++ compiler. instead it shows the compiler flags that would be handed to the C/C++ compiler. the receipts, basically. 🧾
• -showme:link — again, does not invoke the underlying C/C++ compiler. instead it shows the linker flags that would be supplied to the C/C++ compiler. 💅

for literally every other option under the sun, go look at cc(1) and CC(1) (or whatever your underlying C/C++ compilers happen to be). iykyk.

---

💜 DESCRIPTION 💜

so mpicc and mpiCC (and mpic++, which is just a synonym for mpiCC — it exists for filenames that don't support case-sensitive filenames, bless) are convenience wrappers for the local native C and C++ compilers. not me being a whole middle-man, but make it useful. 🙈

here's the tea: translating a LAM program means you gotta link against the LAM-specific libraries, and those may not live in one of the standard search directories of ld(1). it also often needs header files included, and those might not be in a standard location either. so mpicc takes your arguments and passes them along to the local native C compiler, plus the -I, -L and -l options that LAM programs require. that includes all the necessary options for ROMIO and/or C++ bindings support — but only if ROMIO/C++ support was included when LAM was compiled. conditional queen. 👑

mpiCC (and therefore mpic++) is similar, but it invokes the native C++ compiler instead. same vibe, different language. 🌈

the LAM Team strongly encourages using mpicc and mpiCC instead of trying to link to the LAM libraries manually. periodt.

why tho? because doing it the wrapper way lets the specific implementation of LAM change without forcing changes to linker directives in users' Makefiles. and bestie, the specific set of underlying LAM libraries has already changed multiple times, and it will likely change again in future versions. so like… future-proofing. slay. 💅

and honestly? since mpicc/mpiCC are very thin wrappers on top of an underlying compiler, there are very, very few compelling reasons not to use them. fr fr. but when it's genuinely not possible to use mpicc/mpiCC, that's when you reach for the -showme:compile and -showme:link arguments 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

iconic. copy it, don't fight it. 🫶

---

🌟 ENVIRONMENT VARIABLES 🌟

🧚 the C compiler ones

by default, mpicc uses the C compiler that was selected when LAM was configured — that's 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 you can override it with the LAMMPICC environment variable. an older name for this environment variable is LAMHCC — that one also still works, but its use is deprecated. it's giving "we keep you around for nostalgia". 💀

🦋 the C++ compiler ones

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. same energy, same "please stop using this" energy. 🙈

🌸 LAMHOME (proceed with caution, bestie)

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.

translation: mpicc/mpiCC will use the value of LAMHOME as the base to create the -I and -L arguments that get 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. like, capital B, capital I. 🚩

the use of LAMHOME is discouraged, except for some rare configuration cases in oddly networked sites (and in that 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.

because if LAMHOME is unintentionally left set, it can lead to tremendous user confusion. example time: 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. 😭 chaos. actual chaos.

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 LAMHOME, and instead advocates simply setting the PATH properly to switch between multiple LAM/MPI implementations. do that instead. it's cleaner, it's cuter, it works. 💖

---

📝 NOTES 📝

okay, a lil LAM lore for you. previous versions of LAM encouraged the use of hcc and hcp to compile LAM and/or MPI C and C++ applications, respectively. and 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). and now? the executables hcc and hcp are simply symbolic links to mpicc and mpic++, respectively — just in case there's anyone out there that still uses those names. we see you, we love you, the symlinks are for you. 🫶

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). no double-linking, no drama. ✨

---

👀 SEE ALSO 👀

cc(1), CC(1), ld(1), lam-helpfile(5), mpif77(1)

---

and that's the whole page, bestie!! 🎀 this was LAM 7.1.4, dated July, 2007 — yes, 2007, she's vintage and she still slays. now go compile something iconic. 💖✨👑