Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
24 Views

Renaming libiomp5md.dll for 64 bit

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.

0 Kudos
14 Replies
Highlighted
Valued Contributor II
24 Views

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.
0 Kudos
Highlighted
Beginner
24 Views

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?

0 Kudos
Highlighted
Valued Contributor II
24 Views

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.
0 Kudos
Highlighted
Beginner
24 Views

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.

0 Kudos
Highlighted
Moderator
24 Views

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

0 Kudos
Highlighted
Beginner
24 Views

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

0 Kudos
Highlighted
Valued Contributor II
24 Views

>>...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 ).
0 Kudos
Highlighted
Beginner
24 Views

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?

0 Kudos
Highlighted
Valued Contributor II
24 Views

>>...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.
0 Kudos
Highlighted
Valued Contributor II
24 Views

>>...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.
0 Kudos
Highlighted
Beginner
24 Views

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.

0 Kudos
Highlighted
Valued Contributor II
24 Views

>>... 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.
0 Kudos
Highlighted
Beginner
24 Views

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.

0 Kudos
Highlighted
Valued Contributor II
24 Views

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