I'm using Intel Fortran Composer with MKL.
My code is based on F90 format, not F95.
My makefile is run as
LIB = -L/.../opt/intel/mkl/lib -lmkl_lapack -lmkl_intel_thread -lmkl_core -lmkl_intel_lp64
It really runs in other machine but not in my Mac.
In lib directory, the files are ;
libmkl_blas95.a libmkl_intel_thread.dylib libmkl_solver_ilp64_sequential.a
libmkl_blas95_ilp64.a libmkl_lapack95.a libmkl_solver_lp64.a
libmkl_blas95_lp64.a libmkl_lapack95_ilp64.a libmkl_solver_lp64_sequential.a
libmkl_core.a libmkl_lapack95_lp64.a libmkl_vml_avx.dylib
libmkl_core.dylib libmkl_mc.dylib libmkl_vml_mc.dylib
libmkl_intel.a libmkl_mc3.dylib libmkl_vml_mc2.dylib
libmkl_intel.dylib libmkl_p4m.dylib libmkl_vml_mc3.dylib
libmkl_intel_ilp64.a libmkl_p4m3.dylib libmkl_vml_p4m.dylib
libmkl_intel_ilp64.dylib libmkl_p4p.dylib libmkl_vml_p4m2.dylib
libmkl_intel_lp64.a libmkl_pgi_thread.a libmkl_vml_p4m3.dylib
libmkl_intel_lp64.dylib libmkl_rt.dylib libmkl_vml_p4p.dylib
libmkl_intel_sp2dp.a libmkl_sequential.a locale
libmkl_intel_sp2dp.dylib libmkl_sequential.dylib
libmkl_intel_thread.a libmkl_solver_ilp64.a
libmkl_blas95.a libmkl_intel_thread.dylib libmkl_solver_ilp64_sequential.alibmkl_blas95_ilp64.a libmkl_lapack95.a libmkl_solver_lp64.alibmkl_blas95_lp64.a libmkl_lapack95_ilp64.a libmkl_solver_lp64_sequential.alibmkl_core.a libmkl_lapack95_lp64.a libmkl_vml_avx.dyliblibmkl_core.dylib libmkl_mc.dylib libmkl_vml_mc.dyliblibmkl_intel.a libmkl_mc3.dylib libmkl_vml_mc2.dyliblibmkl_intel.dylib libmkl_p4m.dylib libmkl_vml_mc3.dyliblibmkl_intel_ilp64.a libmkl_p4m3.dylib libmkl_vml_p4m.dyliblibmkl_intel_ilp64.dylib libmkl_p4p.dylib libmkl_vml_p4m2.dyliblibmkl_intel_lp64.a libmkl_pgi_thread.a libmkl_vml_p4m3.dyliblibmkl_intel_lp64.dylib libmkl_rt.dylib libmkl_vml_p4p.dyliblibmkl_intel_sp2dp.a libmkl_sequential.a localelibmkl_intel_sp2dp.dylib libmkl_sequential.dyliblibmkl_intel_thread.a libmkl_solver_ilp64.aAs shown above list, there is no file, 'libmkl_lapack.so' or 'libmkl_lapack.dylib'.
When I tried to compile *.f95 after changing previous *.f90 files suffix,
ifort: warning #10147: no action performed for specified file(s)
I followed basic procedure of installing FORTRAN Composer package downloaded from web.
How can I resolve this problem?
链接已复制
13 回复数
elquin,
First of all,could you please try to useLinker Adviserand let us know if you still will have problems.
Additionaly make sure that MKL libs are in the LD_LIBRARY_PATH
Also, you can find several Linking Examples into user's guide (see chapter 5).
--Gennady
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.
ifort doesn't recognize .f95 as an equivalent to .f90.
Thank you for your suggestions.
I searched link and User's Guide but the results are :
LIB = -L/opt/intel/mkl/lib -lmkl_intel_ilp64 -lmkl_sequential -lmkl_core -lpthread
LIB = -L/opt/intel/mkl/lib -lmkl_intel_ilp64 -lmkl_sequential -lmkl_core -lpthread
$ ./myexe_tmp
dyld: Library not loaded: libmkl_intel_ilp64.dylib
Referenced from: /Users/..././myexe_tmp
Reason: image not found
Trace/BPT trap
I tested some other options for linking but same results.
I tested some other options for linking but same results.
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.
Alternatively, use the -rpath linker option.
Alternatively, use the -rpath linker option.
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.
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.
Thank you.
LIB = -L$(MKLROOT)/lib -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -lpthread
After export the DYLD_LIBRARY_PATH, the dyld error about 'libmkl_intel_ilp64.dylib' is corrected.
However, using
LIB = -L$(MKLROOT)/lib -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -lpthread
after type 'make' on command line,
dyld: Library not loaded: libiomp5.dylib
Referenced from: /Developer/opt/intel/composerxe-2011.1.122/mkl/lib/libmkl_intel_thread.dylib
Reason: image not found
Trace/BPT trap
I found that intel_ilp64.dylib and libiomp5.dylib is not in same directory.
Regarding libiomp5.dylib - this is the expected behaviour for the version of MKL integrated intoIntel C++/Fortran Compiler Professional Edition or IntelC++/Fortran Composer XE.
By the default OpenMP libraries (libiomp5.dylib, libiomp5.a) used byMKL are not in/lib directory as in previous versions. They areunder the Intel compiler lib directory now.
--Gennady
Thank you.
What I still struggle is that when I export the DYLD_LIBRARY_PATH to ../mkl/lib, the above error, 'libiomp5.dylib' comes out.
After exporting the PATH to ..compiler/lib, the intel_ilp64.dylib error comes.
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.