MKL Redistribution

[Jorge_Martinis]

Hi!

From a previous thread on this topic, I could not figure out what files must be redistributed when the MKL is dynamically linked (assuming all features and all processors for a platform i.e. IA32).

Is it enough to include the DLL's listed at:

http://software.intel.com/sites/products/documentation/hpc/mkl/userguides/mkl_userguide_win/index.htm

Or are there further dependencies upon delay-loaded DLL's? If so, how do I identify such dependencies?

Thanks,

Jorge

[VipinKumar_E_Intel]

Dear Jorge,

Please refer our KB on this for more details

http://software.intel.com/en-us/articles/which-mkl-libraries-are-redistributables/

Vipin

[Jorge_Martinis]

Thank you Vipin.

From that reference, it seems that the answer to my question is either to distribute the entire redist\(ia32|intel64) content or to pack all of it for redistribution in a custom DLL. Right?

Which MKL libraries are redistributables is well documented. So it is linkage options. Question is how to figure out dependencies if you want to redistribute only a subset of the library. Linking/registration dependencies do not seem enough. Am I missing something here? I wish documentation on this topic would be more detailed.

Jorge

[ArturGuzik]

Hi,

DependencyWalker is your friend if you don't want to redistribute everything neither make custom dll. This will let you check what is depending on which library (dll).

A.

[Jorge_Martinis]

Thank you A!

DW is indeed a very useful tool and we use it extensively. Problem is it would not detect delayed-loaded DLLs and I am of the impression that the MKL loads some DLLs on demand.

Jorge

[eos_pengwern]

We've run up against this same problem; DW tells you which DLLs you need for the application to start up, but says nothing about delay-load DLLs which, if missing, will simply cause the application to disappear without trace when it gets to the point where it would need them.

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?

Thanks,
Stephen.

[barragan_villanueva_]

Hi,

MKL redistributed libraries on Windows are located in the directory:
%MKLROOT%\..\redist\\mkl
where is ia32 or intel64

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.

[eos_pengwern]

Thank you Victor; that's obviously the only supported way of proceeding.

Stephen.

[eos_pengwern]

All right, so now I'm trying to build a custom DLL for my Intel Fortran application and running into some problems with the list of functions that needs to be specified for the 'export=' clause on the command line.

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:

_DNRM2_MKL95
_DSWAP_MKL95
_DPOTRS_MKL95
_DTRTRS_MKL95
_DSYTRF_MKL95

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?

Many thanks,
Stephen.

[SergeyKostrov]

MsDepends.zip enclosed. The utility will show you all dependencies for an application.

Best regards,
Sergey

[mecej4]

The '95' in the name of every one of the unsatisfied externals is a tell-tale. These are "wrapper" routines which interface F95 calls to F77 routines, managing optional arguments and behind-the-scenes allocation of work arrays as needed. The MKL95 routines are used only by Fortran objects, and you must specify the appropriate (target dependent) MKL95 library as an additional library to link.

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.

[eos_pengwern]

Thank you Sergey. Unfortunately I have already determined (by looking at the logs from within Visual Studio) that the application loads different dynamic libraries depending on what it's doing and on what system it's running on, hence the hope for a tool that can capture all the possible library functions which will be needed in order to avoid a crash. If my understanding is correct, Dependency Walker (or MsDepends, same thing...) can't reliably do this.

Stephen.

[eos_pengwern]

I'm surprised this isn't more clearly documented, as I'd have thought quite a lot of users must make use of the MKL95 interfaces, particularly since they were made a standard part of IFORT (I think before version 11 you had to compile them yourself).

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.

Thanks,
Stephen.

[mecej4]

> 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!

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.

[eos_pengwern]

Quoting mecej4

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.

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.

[SergeyKostrov]

Quoting eos pengwern

...
If my understanding is correct, Dependency Walker (or MsDepends, same thing...) can't reliably do this.
...

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.

Best regards,
Sergey