mpif77(1)

💅 mpif77 — the LAM TOOLS era

okay so bestie, welcome to mpif77, aka the little wrapper that compiles your LAM FORTRAN programs for you 🫶 (yes, this is the LAM TOOLS manual, and yes, we're doing this together).

---

✨ SYNOPSIS ✨

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

---

🎀 OPTIONS 🎀

• -showme — does not actually run the underlying FORTRAN compiler. instead it just shows you the whole entire command line that would have been executed to compile your FORTRAN program. it's giving "peek behind the curtain" energy 👀
• -showme:compile — also does not invoke the underlying FORTRAN compiler. instead it shows you the compiler flags that would be handed to the FORTRAN compiler. just the flags. that's it. that's the vibe 💅
• -showme:link — again, does not invoke the underlying FORTRAN compiler. instead it shows you the linker flags that would be supplied to the FORTRAN compiler. linker girlies rise 🔥
• for every other option? go look at f77(1) (or literally whatever your underlying FORTRAN compiler is, no cap).

---

🌸 DESCRIPTION 🌸

mpif77 is a convenience wrapper for your local native FORTRAN compiler. it's not doing anything wild, it's just being a good friend 💖

here's the situation though: translating a LAM program needs the LAM essential services libraries linked in, and those libraries might not live in one of the standard search directories of ld(1). so mpif77 passes its arguments along to the local native FORTRAN compiler, plus the -L and -l options that LAM/MPI programs need. and it includes all the necessary options for ROMIO and/or C++ bindings support (if ROMIO/C++ support was included back when LAM was compiled). periodt.

the LAM Team strongly encourages you to use mpif77 instead of trying to link to the LAM libraries manually by hand like some kind of gremlin 🙈 because this way, the specific implementation of LAM can change without forcing changes to linker directives in your 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. yeah.

and honestly? since mpif77 is a very thin wrapper on top of an underlying compiler, there are very, very few compelling reasons not to use mpif77. like, barely any. but when it's genuinely not possible to use mpif77, you should use the -showme:compile and -showme:link arguments instead. for example:

shell$ f77 -c file1.f `mpif77 -showme:compile`

shell$ f77 -c file2.f `mpif77 -showme:compile`

shell$ f77 file1.o file2.o `mpif77 -showme:link` -o my_mpi_program

iconic behavior honestly ⭐

---

🦋 ENVIRONMENT VARIABLES 🦋

by default, mpif77 uses the FORTRAN compiler that was selected when LAM was configured (that's the --with-fc flag to ./configure, iykyk) as the local native FORTRAN compiler. but you can override that with the LAMMPIF77 environment variable 🫶

an older name for this environment variable is LAMHF77 — that one also still works, but its use is deprecated 💀 so like, technically fine, but pls don't.

if the environment variable LAMHOME is set, mpif77 will use its value as the location of the LAM installation directory instead of the value that was compiled into mpif77. what does that mean? it means mpif77 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 mpif77 was created.

🚨 this is almost always a Bad Idea. like capital-B capital-I 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 be the one to set this up, not you), 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 😭

for example: if LAMHOME points to LAM installation A, but the user's PATH points to LAM installation B, then even though B's mpif77 will be used, the user program will be compiled and linked against LAM installation A. not me finding out the hard way 🙈

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. that's the move. do that one. 💅

---

💜 NOTES 💜

previous versions of LAM encouraged the use of hf77 to compile LAM and/or MPI Fortran applications. in very old versions of LAM, hf77 did not automatically add -lmpi to the command line. hf77 was eventually deprecated and replaced with mpif77. so hf77 is now just simply a symbolic link to mpif77, just in case there's anyone out there that still uses that name 🥺

and it should be harmless to pass in the additional -lmpi; mpif77 should silently do the Right Thing and only link in the MPI library once. one link. one. not two. she's got it 🧚

---

🌈 SEE ALSO 🌈

f77(1), ld(1), lam-helpfile(5), mpicc(1)

---

and that's the whole page bestie, no cap 💖 this was LAM 7.1.4, from July, 2007 — yes, she's vintage, she's a classic, she's still out here compiling your FORTRAN 🎀 slay 👑