You may be looking at a recent version of MKL, where the lapack functions are included in the core and lp64 libraries. Your command line may be suitable for dynamic linking, if you drop the mkl_lapack. ifort doesn't recognize .f95 as an equivalent to .f90.
Check $LD_LIBRARY_PATH. Normally, the startup script ifortvars.sh set this environmental variable. Sometimes, especially if MKL was installed separately from IFORT, the MKL directory is not appended to LD_LIBRARY_PATH. Once you find the correct setting for LD_LIBRARY_PATH, you can put the changes into ifortvars.sh.
If your original choice of lp64 library (32-bit integer arguments) was correct, you shouldn't be switching to ilp64 (64-bit integers) unless you have made the corresponding changes to your MKL function calls. LD_LIBRARY_PATH is the linux environment variable for finding shared libraries at run time. For whatever reason, I believe the spelling is different in MAC OS, e.g. DYLD_LIBRARY_PATH. If you set up your MKL environment correctly accoring to the mklvars script, (or the compilervars script, if installed as part of an Intel compiler installation), this would be taken care of as far as the MKL supplied libraries are concerned.
It is better to supply absolute paths (strung together with ':' as separator, if more than one) for PATH, DYLD_LIBRARY_PATH, etc., because a relative path such as ../mkl/lib becomes invalid immediately after changing to some other directory.
You take on the responsibility of understanding the issues involved, if you don't follow the documented procedure for setting the environment variables. If you don't find adequate documentation for MacOS, that counts in my book as a deficiency in comparison with linux.