Software Archive
Read-only legacy content
17061 Discussions

Is it necessary to use "-offload-option,mic,compiler" to specify search directory when linking?


Dear all,

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-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"\ 

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?

0 Kudos
1 Reply

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.

0 Kudos