Is it possible to delay-load the MKL DLLs?

Is it possible to delay-load the MKL DLLs?

I am calling some MKL LAPACK functions from a
VS 2005 C++ project, linking with mkl_c_dll.lib
and libguide40.lib (V This works.

Some customers may never use the LAPACK functionality,
so I would like to build the program to run whether
or not the MKL DLL's are found, aborting only if they
can't be found when needed.

I changed the link to /DELAYLOAD the MKL DLLs, after
determining the names by trial and error:
mkl_intel_thread.dll and libguide40.dll.
(Any other MKL DLL's are already being dynamically
loaded on demand,which fits right in with my plans.)
This produced a linker error:

LINK : fatal error LNK1194: cannot delay-load
'mkl_intel_thread.dll' due to import of data symbol
link without /DELAYLOAD:mkl_intel_thread.dll

Is there a way around this?

16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Is it possible that nobody here knows the answer?

You can use the LoadLibraryAPI function anywhere in code to load a DLL on demand.


Thank you for the helpful suggestion, but it is not so
simple as you seem to suggest.

Say I want to call dgelss. I must pass LoadLibrary
the name of the DLL which contains this function,
then pass the resulting handle to GetProcAddress
to retrieve a function pointer that I can use to
reference dgelss.

There are many MKL DLL's, none of which exports the
symbol "dgelss", although there is one, mkl_lapack.dll,
which exports a symbol named "mkl_lapack_dgelss".
Perhaps that's the right one... but my program wouldn't
get far enough to find out. The loader's first complaint
(when the MKL DLL's can't be found) is about a DLL
called mkl_intel_thread.dll. I do not reference any
functions in that DLL so, even if I got a handle to it
from LoadLibrary, what would I do with the handle?

I would prefer to let the operating system and the
runtime handle the loading of the MKL DLLs, if that
is possible. Whether it is possible or not is a question
which has not yet been answered on this forum.

Try to add delayimp.lib library to your project. MSVS should consist this library.

The two linker switches of relevance are /lib:delayimp.lib and /delayload:X.DLL. Under the hood a call to a delay-loaded function calls LoadLibrary and GetProcAddress mediated via delayLoadHelper. If the DLL in question has no exports there is little point in loading it, explicitly or implicitly. It'sas simple as that.


Yes, if you want to use /delayload you need delay-load helper function. You can write it by yourself or you can use it from MSVS by adding Delayimp.lib to your project.

Here is article for this theme:


Well ofcourse I am already linking my project with delayimp.lib.

I have successfully delay-loaded other DLLs.

Thelinker errormentioned in my first post arises when

I try to delay-load mkl_intel_thread.dll.

I'm curious as to why you would want to load mkl_intel_thread.dll. It and many of the redists of MKL are undocumented, so how do you know the arguments to pass to them? AFAICT they are invoked by the compiler and weren't designed to be directly called by the developer of an app.


If you look back at an earlier postin this thread you will see (1) why I wantit loaded, and (2) why I can't do it with LoadLibrary/GetProcAddress.

Your first and last post are as clear as mud which might explain why nobody bothers to answer them. You might have greater success by contacting Premier Support.


Could you give small example which illustrate the problem? Full linkage string will be helpful also.

I've been discussing this with the MKL build team. As I currently understand it mkl_intel_thread.dll and mkl_sequential.dll can not be delay loaded. I'm working on understanding the reasons behind this and whether any work-arounds exist. I'll post more when I find out.


Below is the code for an application which has two
modes of operation determined by the command-line.
In one mode it uses MKL services, in the other it
does not.

It is linked with mkl_c_dll.lib and libguide40.lib.
It works as expected when the MKL DLL's are in the
PATH. If the MKL DLL's are not in the PATH, the
program won't run in either mode, and the O/S puts
up an alert that it can't find mkl_intel_thread.dll.

In the next step, I specify that this DLL is to be
delay-loaded, and add delayimp.lib to the link.

The gnarly windows structured exception handler is
required in case a delay-loaded DLL can't be found
on demand, otherwise you'll get an abnormal program
termination, and (on WinXP) a useless invitation to
tell Microsoft about the problem.

But I never get that far. The link fails...

/OUT:smurf.exe" /INCREMENTAL /NOLOGO /MANIFEST /MANIFESTFILE:"smurf.exe.intermediate.manifest" /DELAYLOAD:"mkl_intel_thread.dll" /DEBUG /PDB:"smurf.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 /ERRORREPORT:PROMPT mkl_c_dll.lib libguide40.lib delayimp.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib DelayImp.lib

LINK : fatal error LNK1194: cannot delay-load 'mkl_intel_thread.dll' due to import of data symbol '__imp____mkl_dynamic'; link without /DELAYLOAD:mkl_intel_thread.dll

// File: smurf.cpp
#include "mkl.h"
using namespace std;

int main(int argc, char *argv[])
if (argc > 1)
cout << "bypassing MKL" << endl;
return 0;
double eps = dlamch("prec");// machine precision, declared in mkl_lapack.h
cout << "machine precision " << eps << endl;
cout << "MKL DLL NOT FOUND" << endl;
return 0;

Thanks for your attention. I believe that I have found a workaround, which is to build all MKL usage into a user DLL, and then delay-load that user DLL from my application.

Delay load of mkl_intel_thread.dll/mkl_sequential.dll is impossible now because these libraries contain __imp____mkl_dynamic symbol which must be initialized at the start of application.


Leave a Comment

Please sign in to add a comment. Not a member? Join today