Previously I asked a similar question: cx_Freeze unable fo find mkl: MKL FATAL ERROR: Cannot load mkl_intel_thread.dll
But now I have a subtle difference. I want to run the program without installing anaconda, just within a cmd.exe terminal, but it seems I am doing something wrong or that it is not possible.
After generating my application with python setup.py bdist_msi using cx-freeze, I am able to install and then run it within an anaconda environment, but if I simply open a cmd.exe terminal and run it, I get
INTEL MKL ERROR: The specified module could not be found. mkl_intel_thread.dll.
Intel MKL FATAL ERROR: Cannot load mkl_intel_thread.dll.
However, when running
where mkl_intel_thread.dll
the dll is found, so I think this means it's registered in the system (I am more used to use Linux, so may be I am wrong).
How could I solve this problem?
Maybe another DLL necessary for MKL, such as libiomp5md.dll for example, is missing and causes the error. See Cannot load mkl_intel_thread.dll on python executable, my answer there and its comments.
If this still does not solve your problem, try to manually copy other DLLs from the anaconda environment's library path into the app installation directory and its lib subdirectory. Once you have found which dependency is missing, you can use the include_files option of cx_Freeze to automatize this step in the setup (as you know).
Another possible issue would be that you have an incompatible version of MKL installed on your system and that the frozen application finds this wrong one, but this is unlikely unless you have a 32-bit Python installation on a 64-bit system or have installed the application on another system.
EDIT:
It could still also simply be that the frozen application does not find mkl_intel_thread.dll although where finds it. where looks in the system search path given by the PATH environment variable, while Python looks in the modules search path given by sys.path, which usually does not include the content of PATH, see Where is Python's sys.path initialized from? But on Windows there is a fallback mechanism for registered DLLs (I don't know how it works). Anyway, one should not rely on this fallback as soon as one intends to install and run the application on another system, because the necessary DLL may not be installed there. Thus the necessary dependencies should always be included in the installation directory.