See f77(1) (or whatever your underlying FORTRAN compiler is) for all other options.
The LAM Team strongly encourages using mpif77 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 mpif77 is a very thin wrapper on top of an underlying compiler, there are very, very few compelling reasons not to use mpif77. When it is not possible to use mpif77, the -showme:compile and -showme:link arguments should be used 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
By default, mpif77 uses the FORTRAN compiler that was selected when LAM was configured (with the --with-fc flag to ./configure) as the local native FORTRAN compiler, but this can be overridden by the LAMMPIF77 environment variable (an older name for this environment variable is LAMHF77 -- this also still works, but its use is deprecated).
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. This means that mpif77 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 mpif77 was 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 mpif77 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.