- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am calling some MKL LAPACK functions from a
VS 2005 C++ project, linking with mkl_c_dll.lib
and libguide40.lib (V 10.0.1.015). 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
'__imp____mkl_dynamic';
link without /DELAYLOAD:mkl_intel_thread.dll
Is there a way around this?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can use the LoadLibraryAPI function anywhere in code to load a DLL on demand.
Gerry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Gerry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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: http://msdn2.microsoft.com/en-us/library/yx9zd12s(VS.71).aspx
Andrey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Gerry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
http://software.intel.com/en-us/forums/showthread.php?t=56931#52967
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Gerry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards,
Todd
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
LINKER COMMAND LINE:
/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
LINKER ERROR MESSAGE:
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"
#include
#include
#include
using namespace std;
int main(int argc, char *argv[])
{
if (argc > 1)
{
cout << "bypassing MKL" << endl;
return 0;
}
__try
{
double eps = dlamch("prec");// machine precision, declared in mkl_lapack.h
cout << "machine precision " << eps << endl;
}
__except((GetExceptionCode()==VcppException(ERROR_SEVERITY_ERROR,ERROR_MOD_NOT_FOUND))? EXCEPTION_EXECUTE_HANDLER: EXCEPTION_CONTINUE_SEARCH)
{
cout << "MKL DLL NOT FOUND" << endl;
}
return 0;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Andrey

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page