How to set correct MKL version?

I am trying to deploy a EXE compiled using version 2019a to a machine without having admin privileges. With previous version this always worked when we added <MCRversion>\runtime\win64 in front of the SYSTEM path. However this time after we do this and run the app we get this error:

Error using *

BLAS loading error:

mkl.dll: The operating system cannot run mkl.dll.

Error in etime (line 41)

The system we are trying to deploy to is Windows 7 x64 and has many other things installed on it, including Intel ComposerXE-2011, as I was able to find these variables

ICPP_COMPILER12=C:\Program Files (x86)\Intel\ComposerXE-2011

INTEL_DEF_IA32_MKL_INSTALL_DIR=C:\Program Files (x86)\Intel\ComposerXE-2011\

INTEL_DEF_X64_MKL_INSTALL_DIR=C:\Program Files (x86)\Intel\ComposerXE-2011\

INTEL_LICENSE_FILE=C:\Program Files (x86)\Common Files\Intel\Licenses

INTEL_MKL_10_3_10.3.5001.127_EM64T_INSTALL_DIR=C:\Program Files (x86)\Intel\ComposerXE-2011\

INTEL_MKL_10_3_10.3.5001.127_IA32_INSTALL_DIR=C:\Program Files (x86)\Intel\ComposerXE-2011\

We tried deleting them but even then - the problem persists. As we don't have admin privileges we are restricted to what we can change and by the looks of it - there is some incompatiblity with the MKL library. We have tested the compiled app on a blank Windows 7 machine and it worked fine.

The question is - is there anything else to change at runtime (via batch files) to make sure that the correct versions of MKL files are being loaded and they are not conflicting with anything else on the system?

Kind regards

Ivan

[Jacob Hales]

I wonder if this is related to an issue we just resolved on one of our machines. We followed the first suggestion given here, but we had to copy more than just the two DLLs specified:

https://www.mathworks.com/matlabcentral/answers/375270-why-does-my-matlab-compiler-standalone-application-fail-to-start-with-a-the-operating-system-cannot#answer_298436

In case the link goes stale:

This error may occur if you have an older version of ssleay32.dll and libeay32.dll in your Windows system32 directory. To resolve this issue, either:

1. Place a copy of MATLAB's SSLEAY32.DLL and LIBEAY32.DLL (from the bin\win64 directory) next to your standalone executable. The directory from which the application loaded has a higher priority than system32, so this should allow the application to use the DLLs which it needs, or

2. Remove SSLEAY32.DLL and LIBEAY32.DLL from the system32 directory; the standalone can then use the one included with MATLAB. This may break other applications however which rely on the DLL being in system32. So, alternatively you may want to update SSLEAY32.DLL and LIBEAY32.DLL in the system32 directory, for example by replacing it with the copies included with MATLAB or perhaps you could update the application which installed this DLLs in the first place, if you know which application this was.

PS: To identify that this is indeed the cause of the issue you can run a Dependency Walker profile on the standalone application, in which you would see ssleay32.dll and libeay32.dll being loaded from a different location than MATLAB/MCR bin\win64 directory and you should see that certain entry points are not found in that DLL. Note that this occurs way before libmwlmgrimpl.dll is loaded, it happens when the POCO libraries are loaded first and then libmwlmgrimpl.dll fails when it tries to use these POCO libraries.

[Sahin Ozsoy]

Jacob, what other dlls did you copy? Also, I do not see any SSLEAY32.DLL or LIBEAY32.DLL on my system.