Renaming libiomp5md.dll for 64 bit

[crispybits]

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.

[SergeyKostrov]

Could you explain what problem do you have with libiomp5md.dll? Here are some Generic notes: There are some differences between 32-bit and 64-bit Intel DLLs ( especially when it comes to Waterfall MKL DLLs ) and I wouldn't follow that path ( I mean renaming any Intel DLLs ). In case of MKL DLLs I would use a solution based on a call to LoadLibrary Win32 API function. However, it requires changes in project settings and source codes because Intel MKL libraries should not be used during linking phase.

[crispybits]

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?

[SergeyKostrov]

This is a short follow up. >>...Is that safe given that my application will never call any method before another has finished?.. Yes, it is safe becase on Windows 64-bit platforms 64-bit and 32-bit subsystems, and applications, use different sets of environment variables.

[crispybits]

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.

Dynamic linking:

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

Static linking:

- Risk of errors and

- Depricated. That means I won't be able to upgrade to a new version of MKL.

[Gennady_F_Intel]

I completely agree with crispybits, especially in the case when you will met some unexpected issue.

[crispybits]

Thanks for the confirmation Gennady, even though it's not good news :(

[SergeyKostrov]

>>...couldn't get anything to work using #pragma comment... It should work and here is an example how I use it: ... #if ( defined ( _M_IX86 ) ) #ifdef _DEBUG #pragma comment ( lib, "../Bin/Debug/[ SomeName ]D.lib" ) #else #pragma comment ( lib, "../Bin/Release/[ SomeName ].lib" ) #endif #endif #if ( defined ( _M_X64 ) || defined ( _M_AMD64 ) || defined ( _M_IA64 ) ) #ifdef _DEBUG #pragma comment ( lib, "../Bin/Debug/[ SomeName ]64D.lib" ) #else #pragma comment ( lib, "../Bin/Release/[ SomeName ]64.lib" ) #endif #endif ... As you can see 32-bit and 64-bit libraries are located in the same folders ( for Debug and Release Configurations ).

[crispybits]

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?

[SergeyKostrov]

>>...Is this in the source for your application, not the library itself? It is in a common header file. Please take a look at MSDN for more technical details on how #pragma comment needs to be used if something is still not clear. In overall, 32-bit applications are linked with 32-bit libraries, and 64-bit applications are linked with 64-bit libraries. >>...It does't seem quite possible... There is No any magic here and the solution I use is a classic one.

[SergeyKostrov]

>>...Can you give me some pointers on where to find out how to use LoadLibrary for this purpose? Please take a look at MSDN and applications of that functions are very simple.

[crispybits]

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.

[SergeyKostrov]

>>... It doesn't seem to allow you to rename the dll... Yes, that is correct and #pragma comment directive was not designed to do this.

[muir]

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

http://stackoverflow.com/questions/280485/how-do-i-rename-a-dll-but-still-allow-the-exe-to-find-it

've added this code to my dll

[cpp]

#include <windows.h>

#include <delayimp.h>

FARPROC WINAPI delayHook(unsigned dliNotify, PDelayLoadInfo pdli)
{
    switch(dliNotify)
    {
        case dliNotePreLoadLibrary:

            if(strcmp(pdli->szDll, "libiomp5md.dll" ) == 0 )
            {
#ifdef _WIN64
                    return (FARPROC)LoadLibrary(L"libiomp5md64.dll");
#else
                    return (FARPROC)LoadLibrary(L"libiomp5md32.dll");
#endif
            }
            break;

        default:
            return NULL;
    }
    return NULL;
}

PfnDliHook __pfnDliNotifyHook2 = delayHook;

[/cpp]

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.

[SergeyKostrov]

>>... I assume that completely different applications (.exe's) on the same PC using different versions of the library won't cause >>any data corruption... Yes, that is correct since both applications won't share address spaces and this is by design of Windows operating systems.