Compiling with “-mkl –static” causes a linker error on Red Hat EL 6.x while the same compilation on RHEL 5.x works correctly. Here are the commands to reproduce the problem:
$ source /opt/intel/composer_xe_2013.5.192/bin/iccvars.sh intel64
$ icc -mkl -openmp -static dgemm.c (Copy the code from manual)
ld: cannot find -lpthreadld: cannot find -lm
Once we solve the problem by:
$icc -mkl -openmp -static -L/usr/lib/x86_64-redhat-linux5E/lib64/ dgemm.c
New errors produce:
dgemm.c:(.text+0x465): undefined reference to ‘dgemm’ or
xxxmm.c:(.text+0x465): undefined reference to ‘__isoc99_fscanf’
Library order in static link does matter. The linker in Linux only looks all symbols one time. So if you list one or more *.o objects after one or more static libraries that contain symbols needed by the objects, the linking will fail.
System library in static link is another issue too. The Linux* community is trying to discourage static linking and moving the community to a dynamic linking model. So recent Linux distributions are not shipping/installing GLIBC/static library by default (or the static libraries is not in the searched path). And recommend two main solutions for this problem: (1) make all required static libraries available either pointing to the non-default location, by download and installation, or by building them from source, or (2) switch to a different linkage model such as mixed dynamic and static linkage or perhaps a complete dynamic linkage model.
In the above case, there are mainly two problems.
1. Root cause: The option –static means you need the static libraries of GLIBC, Intel® MKL, and OpenMP* (also explained at http://software.intel.com/en-us/articles/error-ld-cannot-find-lm/). The root cause is either that RHEL 6, FC12, 13, 14 do not ship with static versions of GLIBC or that the libraries are in a directory that is not normally searched during the link step. Thus, there is no static version of libm to link against by default.
Solution to “cannot find pthread/ld/m”, and “undefined reference to __isoc99_fscanf”
Please add the path of static versions of GLIBC in command line or LIBRARY_PATH, it may be -L/usr/lib/x86_64-redhat-linux5E/lib64/ or install the static version of GLIBC for your Linux* distribution.
Note: -static-intel is to statically link the Intel libraries and dynamic link system libraries, which is recommended if you want static Intel library only.
2. Root cause: the position of –mkl matters
There are 4 kind of command lines:
1. $ icc -mkl dgemm.c
2. $ icc dgemm.c –mkl
3. $ icc dgemm.c -mkl –static-intel
4. $ icc -mkl dgemm.c -static-intel
The first 3 models can be build successfully with composer_xe_2013.5.192 . The 4th gives an error (see also athttp://software.intel.com/en-us/forums/topic/393920):
Solution to Undefined reference to ‘dgemm’
The 4th model does not work because the static references in dgemm.o can only be resolved by libraries passed after the object. So please try
$ icc dgemm.c –mkl -openmp –static-intel or
$ icc dgemm.c -Wl,--start-group $MKLROOT/lib/intel64/libmkl_intel_lp64.a $(MKLROOT)/lib/intel64/libmkl_intel_thread.a $MKLROOT/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread –lm
See more in Intel MKL Link Line Advisor:http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
You may see several warnings with the command:
/opt/intel/composer_xe_2013.x.x/mkl/lib/intel64/libmkl_core.a (ueaa_prv_load_backend_lib.o): In function `ueaa_prv_load_backend_libs':
../../../../serv/offload/ueaa/core/coi2/ueaa_prv_load_backend_lib.c:(.text+0x233): warning: the 'dlopen' symbol can be made statically available but the statically linked application may link dynamic at runtime if certain components are present. Moreover, those components may also rely on shared libraries such GLIBC.
Root Cause: such warnings with the -static option appear since the automatic offload support was added for the Xeon phi processor (Intel® MKL 11.0). The automatic offload infrastructure uses some components of the MPSS if present; hence it is dynamically linked using dlopen.
Note: disabling automatic offload using the mkl_mic_enable() service function or the MKL_MIC_ENABLE environment variable does not link in a “more static” manner – it would just disable this functionality (which might present in a system).
Reference: F393920, Q698895, DPD200345901,DPD200238847