Dummy library removed and recommended solution:
As the claim in Compatibility libraries (also known as dummy libraries) no more available,  since MKL 10.2, we remove the dummy libraries completely. You are strongly encouraged to link Intel MKL library with layered mode.  

Please refer to Intel® Math Kernel Library Link Line Advisor 

or the map table in For easily migrating from Intel® MKL 9.x to 10.x

For some users who may still want to use one library instead of the "complex" combination of layered libraries, you may create the "dummy" library manually.

Intel® MKL for Linux

For example, you had one library libmkl.so from earlier version which worked and you hope keep use the name in your link line or makefile, you can create a "dummy" library manually,

For example, you are using intel compiler, threading mode, lp64 interface, create the dummy library by command

$ vi libmkl.so

add the below text in the fake file

GROUP (-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core)

Keep it into the MKL library directory.

If you had used static library -lmkl_em64t,    

   $ vi libmkl_em64.a

Add the text

GROUP (libmkl_intel_lp64.a libmkl_intel_thread.a libmkl_core.a)

Keep it into the mkl library directory.

Intel® MKL for windows

In case of Windows you may create c file with the following code:

// dynamic library link

#pragma comment(lib, "mkl_intel_c_dll")
#pragma comment(lib, "mkl_intel_thread_dll")
#pragma comment(lib, "mkl_core_dll")
#pragma comment(lib, "libiomp5md")

 // static library link
//#pragma comment(lib, "mkl_intel_c")
//#pragma comment(lib, "mkl_intel_thread")
//#pragma comment(lib, "mkl_core")
//#pragma comment(lib, "libiomp5md")

void dummy_func_somethingrandom_1234217846()

{ return; }

Compiling this code with any compiler and making lib out of it:

>cl -c mkl_ia32.c

>lib mkl_ia32.obj

The fake function is essential, since in some cases Microsoft Visual Stuio linker can report an error while linking library without any functions in it.

TroubleShooting regarding dummy library: 

1. Problem with Linking Applications to Intel MKL 10.0 for Linux* Dummy Shared Librares
2. Errors linking Intel® compilers with Intel® MKL 10.x
3. "MKL FATAL ERROR: Cannot load neither xxxx" with Intel MKL 10.x
4. If you are link mkl library pure layaered library by configure as below

./configure --mkl_lib='/opt/intel/mkl/10.2.x.0xx/lib/em64t/libmkl_intel_lp64.a
/opt/intel/mkl/10.2.x.0xx/lib/em64t/libmkl_sequential.a
/opt/intel/mkl/10.2.x.0xx/lib/em64t/libmkl_core.a'

Please note the mark '  ' are required.

or vice versa message
This can cause performance degradation.

Cause:

Both libiomp5md.dll and libguide40.dll are Intel OpenMP Runtime library. The libiomp5md.dll is new Intel OpenMP* Compatibility library while the libguide40.dll is legacy OpenMP library. Since Intel® MKL 10.1.0.018 and Intel® Compiler 11.x and later,  the default OpenMP runtime library for Intel MKL has been changed from libguide to libiomp.  Please see <http://software.intel.com/en-us/articles/openmp-support-change/>
 
The error is caused by multiple OpenMP libraries were linked in same application. For example, you have two mkl versions MKL 10 and MKL 10.2.1 are linked in same appliation. The error arises because of the duplicate initialization of OpenMP Runtime library from MKL 10 which link libguide40 and MKL 10.2.1 which use libiomp5md .

Please note, the libguide40.dll sometimes were linked implicitly, e.g. by third-party library, custom dll or by dummy library mkl_c.lib in previous MKL version.

Solution:

Please remove one of them and keep only one OpenMP runtime library.

We recommend using and distributing libiomp5md.dll (located in the \bin directory), as libguide40 will be obsolete.

For the third-party library or custom dll which have used the libguide40.dll from pervious  MKL version, in order to avoid such kind of issue, we strongly recommend rebuild your library with libiomp5md.dll.

Symptoms

When building with Intel® Math Kernel Library for Windows* version 10.0 using the xilink linker from the command line or within the Microsoft Visual Studio* IDE, the following error messages may occur:

Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3)
Link: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 3) or(0): internal error: backend signals
xilink: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 4)
xilink: error error_during_IPO_compilation: problem during multi-file optimization compilation (code 4)

When using the Intel® C++ Compiler for Windows*, these errors have occurred when the /Qipo compiler option is used with the xilink linker from the command line.

When using the Intel® Visual Fortran Compiler for Windows*, these errors have occurred when building within the Visual Studio IDE, which uses the xlink linker.

Solution

Intel® Math Kernel Library for Windows version 10.0 introduced new library naming conventions, with "dummy lib" references to the older Intel® MKL libraries. However, there is a format problem with the Intel MKL "dummy libs" files that is causing problems for the Intel xilink tool. Correct the problem by modifying link information for the command line or the Visual Studio link information to specify the new names of the 10.0 Intel MKL libraries.

Linking from the Command Line

When link errors occur, correct the problem by replacing references to the Intel MKL dummy libraries on the link command with explicit references to the libraries listed in the dummy libraries. See the explicit Intel MKL library references listed below.

Linking from within Microsoft Visual Studio

In the Visual Studio IDE, replace the references to the dummy libraries in Project » Configuration Properties » Linker &» Input » Additional Dependencies. See the explicit Intel MKL library references listed below.

For IA-32 Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references mkl_c_dll.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_s_dll.lib mkl_intel_s_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_c.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib mkl_s.lib mkl_intel_s.lib mkl_intel_thread.lib mkl_core.lib mkl_scalapack_dll.lib mkl_scalapack_core_dll.lib mkl_scalapack.lib mkl_scalapack_core.lib mkl_cdft_dll.lib mkl_cdft_core_dll.lib mkl_cdft.lib mkl_cdft_core.lib

For Intel® 64 Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references mkl_dll.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_em64t.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib.lib mkl_scalapack_dll.lib mkl_scalapack_lp64_dll.lib mkl_scalapack.lib mkl_scalapack_lp64.lib mkl_solver.lib mkl_solver_lp64.lib mkl_cdft_dll.lib mkl_cdft_core_dll.lib mkl_cdft.lib mkl_cdft_core.lib

For IA-64 [Intel® Itanium®] Compilers

Intel MKL dummy library Replace with explicit Intel MKL library references mkl_dll.lib mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib mkl_ipf.lib mkl_intel_lp64.lib mkl_intel_thread.lib mkl_core.lib mkl_scalapack_dll.lib mkl_scalapack_lp64_dll.lib mkl_scalapack.lib mkl_scalapack_lp64.lib mkl_solver.lib mkl_solver_lp64.lib mkl_cdft_dll.lib mkl_cdft_core_dll.lib mkl_cdft.lib mkl_cdft_core.lib

The LAPACK least squares function dgelss gives a different results on Linux* compared with Windows*. Though, it is difficult to get a bit-to-bit correspondence values on both systems, but considering the following may help to get consistent results.

1. Align the arrays to 16 bytes boundary.
2. Use 80-bit precision instead of the default 64-bit on IA32, which is used on the Intel® compiler. This can be set by using /Qpc80 compiler flag on Windows.

For a rank-deficient matrix, it is not easy to get deterministic results. For a rank 2 matrix, only 2 singular vectors will be computed to the working precision and other singular vectors could be any vectors that complement the orthonormal system along the first two, because SVD algorithm becomes unstable in the range of very small singular values. It is unavoidable and we can guarantee bit-to-bit correspondence of the results only on the systems with absolutely the same architecture, same MKL version, same arrays alignment, same FP units flags (precision, rounding etc), running in the same number of threads. Otherwise, ill-conditioned problems cause the different results from the practical point of view, in case of SVD returns several singular values equal to zero (to the working precision). The following should be considered to avoid the different behaviours.

1. Least square problems still should be solved in deterministic way, because the algorithm doesn't use "bad" singular vectors corresponding to zero singular values to compute the solution.
2. If user needs a deterministic full set of singular vectors, not only for non-zero singular values, user may rebuild "bad" vectors using one of the deterministic procedures making orthonormal vectors to some initial orthonormal subset of "good" vectors. At any rate, user has to examine the singular values to understand whether the singular vectors are meaningful or not.
3. Using 80-bit precision which doesn't mean that user doesn't take advantage of SIMD instructions - it means that internal FPU computations will be taken using 80-bit precision. On IA32, MKL has both vectorized and non-vectorized x87 code. Most performance relies on the vectorized code and setting 80-bit FPU precision doesn't hurt vectorized code at all. Neither 80-bit precision flag affects the x87 code performance, but makes x87 code more accurate. On Windows user could set it by compiling main program with /Qpc80 flag using Intel compiler.