Hello. I want to use both the 32 and 64 bit versions from the same folder. How can I rename one of them to avoid conflict?
Alternatively, I could statically link on one platform and dynamically on the other. Is that safe given that my application will never call any method before another has finished? That is, the 64 bit process in my application has only 1 thread although 64 bit MKL may be used at the same time as a 32 bit MKL. I know static linking this library is deprecated but it seems like a simple solution.
You're just the person I was hoping to meet! I saw your other post http://software.intel.com/en-us/forums/topic/280281 about this topic but couldn't get anything to work using #pragma comment
My problem is that I need both 32 and 64 bit versions but I can't put them both in the same folder as my application because of the filename conflict. I have other (managed) dlls which are shared by both the 32 and 64 bit processes so I can't easily move the 64 bit files to another folder either.
Can you give me some pointers on where to find out how to use LoadLibrary for this purpose?
I guess there's no good solution. From various other threads, this looks like a combination of design problems in OpenMP - the unfixable static linking bug together with the unfortunate choice of identical file names for different platforms.
- Requires either a more complicated directory structure to separate the two versions or
- An installer to install them both globally which is bound to create endless hard-to-diagnose problems on the user's end.
- Risk of errors and
- Depricated. That means I won't be able to upgrade to a new version of MKL.
Is this in the source for your application, not the library itself? It does't seem quite possible. How does it know what library you're renaming? Do you also rename the .lib files? Won't it then fail when it tried to link the original lib?
I think #pragma comment lib just provides a way to link the lib conditionally rather than always. It doesn't seem to allow you to rename the dll. You're probably using dlls that were already compiled with unique names. I don't think LoadLibrary can be any use either. The program won't even start if it can't find the original libiomp5md.dll so there's no opportunity to load it again from myrenamed_libiomp5md.dll.
I've been having a great deal of trouble with this also, but have managed to rename the dll. I'd by far prefer to statically link libiomp5.
I assume this will causes the same potential problems as statically linking the library would have, but its not a problem in my application. I assume that completely different applications (.exe's) on the same PC using different versions of the library won't cause any data corruption - ie only dll's used in the same exe that link to different versions of the dll would cause a problem. The documentation is not overly clear to me.
Take a look at this post here
've added this code to my dll
FARPROC WINAPI delayHook(unsigned dliNotify, PDelayLoadInfo pdli)
if(strcmp(pdli->szDll, "libiomp5md.dll" ) == 0 )
PfnDliHook __pfnDliNotifyHook2 = delayHook;
I renamed the 32 and 64 bit versions of libiomp5md.dll to libiomp5md32.dll and libiomp5md64.dll respectively.
The original libiomp5md.dll needs to be delay loaded. In Visual Studio 2010, in "Project/Properties/Configuration Properties/Linker/Input" set "Delay Loaded Dlls" to "libiomp5md.dll"
You might need to remove or rename any copies of libiomp5md.dll in the search path to make the dll load fail and cause it to load the new one. They exist in the MKL installation directory.
I expect it's possible to embed the dll within the dll/exe file itself, effectively producing the same result as a statically linked lib, though with considerably more effort. I've not tried it yet. I'd appreciate it if Intel could make the lib available again.