recently I'm new to MIC and I follow Intel MKL link line advisor to wrote Makedown like this:
TK_INC_PATH ?= /opt/intel/mkl/include TK_LIB_PATH ?= /opt/intel/mkl/lib/intel64 MIC_LIB_PATH ?= /opt/intel/mkl/lib/mic TK_LIB2_PATH ?= /opt/intel/lib/intel64 icc -offload-attribute-target=mic -I$(TK_INC_PATH) -c *FILE_ONE* ....repeat for other source files.... icc -L$(TK_LIB_PATH) -L$(TK_LIB2_PATH) -ldl -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 \ -offload-attribute-target=mic\ -offload-option,mic,compiler,"-L$(MIC_LIB_PATH) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5"\ -offload-option,mic,ld,"-L$(MIC_LIB_PATH) -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core"\ *ALL_OBJECT_FILES*
I know the real shared object is come from "LD_LIBRARY_PATH" and "MIC_LD_LIBRARY_PATH". So, why not use the same search directory, such as "mkl/lib/intel64"? Must we specify search directory for MIC when linking?
The libraries in the specific unique sub-directories (intel64 and mic) are specifically built for use on the host (intel64) and the coprocessor (mic); thus, libs in the intel64 directory are not usable on the coprocessor so you cannot use a path to those for both the host and coprocessor links.
If your app requires a unique set of MKL libs (different than the default set) then you need to provide that list and the corresponding path (-L) for each the host and coprocessor compilation/link steps.
If your app can use the default set of MKL libraries (for both the host and coprocessor) as chosen by the compiler’s -mkl option, then you may be able to simply use the -mkl option during compilation and linking and avoid the -offload-option for each.