I have wrapped the code required to do an Akima spline interpolation in the attached source code. When I link my main application statically with the MKL, it runs fine. However, with dynamic linking (i.e. with the need of MKL runtime libs) I experienced a strange behavior. First of all I did not know which runtime libs I needed so when trying to call the dfdNewTask1D routine simply terminates my application; after several tries (running in console mode) I found that mkl_vml_avx2.dll and mkl_vml_p4.dll were required. I loaded manually these dlls and my code runs fine and I unload them after. However without exiting my app, if I run again the same calculation (after loading again the same set of dlls), the call to the dfdNewTask1D routine generates an exception an my application crashes (under debug, the call to dfdNewTask1D never returns because an exception is generated somewhere). The runtime dlls I load/unload at/after every run are:
I don't know if I need other dlls or what is going wrong.
Just some additional information.
- My compiler version is 126.96.36.199.
- The MKL version I uses is probably 188.8.131.52 (this is the version number of all the dlls in the redist folder)
- Sometimes I found that running several consecutive calculations runs but this seems not reproducible all the time.
What do you mean by "I loaded manually these dlls and my code runs fine and I unload them after."?
Do you explicitly load mkl's dlls at runtime by calling LoadLibrary, GetProcAddress ... ?
Yes, I manually load (using the LoadLibrary API function) the dlls to be sure that the dll I need are the one that I install. I don't need to use the GetProcAddress function because my dll is compiled using the /Qmkl:parallel option. I already posted a question relating to this problem in the past but for another dll (see: https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/707508). I really think that it's a problem with the mkl version I use because I tried to use the same files from the 2019 release (only the mkl_*.dll files) and I'm not getting this error. So I guess that there is a problem with this mkl version (184.108.40.206) when linking with dynamic libraries.
Hi Phil, MKL doesn't validate such linking mode you use. In the case, if you continue to stay with version 11.0, then you may try to submit the issue to the Intel Online Service Center and provide there all your business reasons, but I have to warn you that only 3 latest versions are officially supported. These are MKL vv2019,2018 and 2017 correspondingly. Thanks, Gennady
What do you mean by "MKL doesn't validate such linking mode you use". Is this not the same if I install all the redist libraries using a standard install process ? The may difference it that I don't want to install all the compiler and MKL redist libs which use a lot of disk space and I want to be sure of the libraries I use, I don't want to get any trouble with other installations already present on the customer computer nor create incompatibilities for other software.
I will probably move to a more recent version of the compiler and MKL or switch to another way of doing splines.
About taking too much space: If you are working on your computer where you are not worried so much about space, and deploying an executable to the customer computer, you can build a static executable for the customer that contains only what is needed.
This is what I was using in the past, when what we call "modules" were packed in the same dll, however today each individual module has its own dll and because there are a lot them (~100), building each of them statically would increase a lot the install package, the space required for installation and also the loading time for each dll. For all these reasons, I decided to use runtime libs. Furthermore, I've noticed that as soon as you build an executable or dll statically with the MKL, it's size increase a lot !
I think that the best option for us is to switch to a more recent version of the compiler and MKL (we are still using the 2013 versions, 220.127.116.11 for the compiler) to solve this problem and add the missing libraries to our process.
And a potentially helpful resource to shrink custom dll's - https://software.intel.com/en-us/mkl-windows-developer-guide-building-custom-dynamic-link-libraries
It's a (not simple) process to determine which dll's are needed.