We've been trying to isolatethe correct set of DLLs by:
- running the application in debug mode with the full set of DLLs available
- putting breakpoints just after at each call to an MKL function
- looking in the "Output" window to see which DLL is delay-loaded at the time of making the function call.
This would be fine, except that we've noticed that different DLLs are loaded on different machines - for example, one PC may load mkl_p4.dll and another mkl_p4m3.dll at the same point.
Is there are documented rule that we can use to identify the minimum set of DLLs we would need to redistribute in order to have our code run robustly on all platforms?
MKL redistributed libraries on Windows are located in the directory:
In general all that MKL libraries are needed to run on all machines.
However, there exists a way to create just one dynamic MKL custom library to mimimize your dependences.
Please see MKL documentation.
Following the advice in the documentation,in order to identify which functions I need, Itried to link my application with all the MKL .lib filesremoved from thelink line, to see what unresolved symbols were reported. The resulting list was:
The list is surprisingly short, since my application also relies heavily on descnd, dtrnlspbc_* and djacobi_*, but in any case I put them into a text file, referenced the text file from my nmake command line, and proceeded.
Now, 'nmake ia32' doesn't seem to recognise any of the routine names suffixed with _MKL95. If I take the suffix away, then the custom DLL will build without errors, but then when I try to link my application with the custom .lib file it still complains that it can't resolve the above symbols.
Can anyone please suggest what I am missing here, both in respect of these routine names and also how I should be linking dtrnlspbc_* etc?
Applications written in C and Fortran 77 do not use MKL95 routines, and most of the written material on building a custom MKL DLL does not account for using the MKL95 interfaces.
To try to get a handle on the underlying library functions, I tried compiling with just 'mkl_blas95.lib' and 'mkl_lapack95.lib' on my link line, leaving out the other libraries from the link-line advisor that I normally add, but this then compiled without error!
So I'm none the wiser; I'm beginning to fear that I'll be sending out the whole MKL redistributable directory for some time to come.
This is not surprising, since information on library (DLL) dependencies is often embedded in the library, making it convenient for the user. However, when one wishes to do surgery on the guts of the libraries, the details become necessary.
Should we request Intel to add a /Qmkl95 option, to use the MKL95 libraries in the same convenient fashion that /Qmkl pulls in the MKL libraries?
Have you tried using the /MAP option of the linker to list all the libraries that are needed/linked-in into your application? You could look at the map file and find out all the MKL DLLs that your application needs, as an alternative to using Dependency Walker.
Another possible route for you is to tell your customers to download and install the MKL redistributables directly from the Intel servers, instead of taking responsibility for distribution yourself.
Sadly even the .map file doesn't reference any of the flavours of mkl_p4 (mkl_p4.dll, mkl_p4m.dll etc.), which are delay-loaded during a calculation but with different files chosen on different systems, it seems.
Yes, it is correct. The utility does a static analysis of an executable or a DLL. It doesn't do a runtime analysis
and doesn't show any dependencies related to loading some DLLs with 'LoadLibrary' or 'LoadLibraryEx'
Win32 API functions.