Can multiple versions of MKL be used in the same process?

Question

We are developing a plugin for a 3rd party application in a Windows environment (each plugin is a DLL file stored in a predesignated folder). The application uses Intel MKL 10.3.9.1 internally, and ships with MKL DLLs in its installation folder.

Our plugin DLL also depends on MKL, but we must use a later version (11.1.3.1) because we use VS2012 (older versions of MKL do not support it). We place the MKL DLLs in the plugin folder, alongside our own DLL which is built against the said version of MKL. This is how our code links with MKL (in the x64 configuration):

#pragma comment(lib, "mkl_intel_lp64_dll")
#pragma comment(lib, "mkl_intel_thread_dll")

When the application runs, it loads the MKL 10.3 DLLs from its folder. When the plugin DLL is loaded it seems as though the MKL 11.1 DLLs are loaded (at least the files are accessed), but then the application freezes (if a debugger is attached, I see access violation exceptions). If the MKL-dependent portions of our code are replaced by stubs, effectively removing the dependency on MKL, the application runs and uses the plugin just fine.

My guess is that these problems arise because our DLL expects to work with MKL 11.1 but is actually getting the previously loaded MKL 10.3 (note that the DLLs of the different MKL versions have the same names).

Does anyone know if it is possible to load two different versions of MKL into the same process?

Answer 1

I managed to resolve this problem and allow our plugin to use a different version of MKL than that of the hosting application by taking the following steps (inspired by this thread, referred to by this answer - which describes a different but related scenario):

1. Put the MKL 11.1 DLLs in a subfolder under the plugin folder, called Intel.MKL (instead of the plugin folder itself, where our plugin DLL is stored).

2. Add a file named Intel.MKL.manifest in the said Intel.MKL folder with the following content:

   <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
       <assemblyIdentity name="Intel.MKL" processorArchitecture="amd64" version="11.1.3.1" type="win32" />
       <file name="mkl_core.dll" />
       <file name="mkl_intel_thread.dll" />
   </assembly>
   

3. In the code of our plugin DLL, add this to some *.cpp file:

   #pragma comment(linker, "/manifestDependency:\"name='Intel.MKL' processorArchitecture='amd64' version='11.1.3.1' type='win32' \"")  
   

4. Keep the #pragma comments that refer to MKL's import libraries as they appear in the question. Also, there's no need to create a manifest for the MKL 10.3 DLLs in the application's own binary folder, and no need to touch the application EXE.

With these changes, I can see the application loads the MKL 10.3 DLLs from its own folder when it starts, and the MKL 11.1 DLLs from the Intel.MKL subfolder when the plugin is loaded. When calling mkl_get_version_string from the plugin, the expected version (11.1) is indeed returned.