Can the name of libiomp5md.dll be different for different platforms?

[FengR]

Hi all,

I am building my projects for different platforms(X64&Win32). In my projects, I have used OpenMP and want to dynamically link OpenMP. However, when I tried to build instlallation package, I have to distinguish the target platforms before I select proper libiomp5md.dll. Is there possible for me to rename libiomp5md.dll to different names? Or rename the lib name when I link libiomp5md.lib to my projects?

Thanks

FengR

[SergeyKostrov]

Quoting FengR

...
I have to distinguish the target platforms before I select proper libiomp5md.dll. Is there possible for me to rename libiomp5md.dll to different names? Or rename the lib name when I link libiomp5md.lib to my projects?
...

1. Here is a generic\abstruct example:

- Let's say you have two Dlls & two Libsfor Win32 & Win64 ( all of them forRelease configuration )

For Win32:
DllLibrary.lib ( import library ) and DllLibrary.dll

For Win64:
DllLibrary.lib ( import library ) and DllLibrary.dll

As you can see names are the same.

- Renaming could be done as follows:

For Win32:
DllLibrary32.lib ( import library ) and DllLibrary32.dll

For Win64:
DllLibrary64.lib ( import library ) and DllLibrary64.dll

- In case of aDebug configuration a suffix'd' could be added, like DllLibrary32d.lib amd DllLibrary32d.dll

2. It also could be done with '#pragmacomment ( lib :"< a path to an import library >" )' directive.

Note: I would prefer the second way because it doesn't affect aproject file and it is more flexible.

Best regards,
Sergey

[SergeyKostrov]

Here is an example in case of aC/C++ project with support for three different Windows CE \Mobile platforms:

Note: In totalthere isa support for7 different platformsin a project I'm currently working on

...

#if defined ( _WIN32CE_MSC )

#ifdef _RTDEBUG

#if defined( WIN32_PLATFORM_PSPC ) && !defined ( WIN32_PLATFORM_WM50 )
#pragma comment ( lib, "../../Bin/Debug/ScaLibPpcD.lib" )
#endif

#if defined( WIN32_PLATFORM_WFSP )
#pragma comment ( lib, "../../Bin/Debug/ScaLibSpD.lib" )
#endif

#if defined( WIN32_PLATFORM_PSPC ) && defined ( WIN32_PLATFORM_WM50 )
#pragma comment ( lib, "../../Bin/Debug/ScaLibPpcWM5D.lib" )
#endif

#else

#if defined( WIN32_PLATFORM_PSPC ) && !defined ( WIN32_PLATFORM_WM50 )
#pragma comment ( lib, "../../Bin/Release/ScaLibPpc.lib" )
#endif

#if defined( WIN32_PLATFORM_WFSP )
#pragma comment ( lib, "../../Bin/Release/ScaLibSp.lib" )
#endif

#if defined( WIN32_PLATFORM_PSPC ) && defined ( WIN32_PLATFORM_WM50 )
#pragma comment ( lib, "../../Bin/Release/ScaLibPpcWM5.lib" )
#endif

#endif

#endif
...

[Steven_L_Intel1]

No, you cannot rename the DLL as otherise it will not be found. However, Windows x64 is smart enough to skip over a 32-bit DLL when it is loading a 64-bit image. When the Intel DLLs are installed, they are put into separate folders and, on 64-bit system, both are added to PATH.

Why don't you use the .msm we provide for the Intel redistributables?

[SergeyKostrov]

Steve,

Yes You Can becauseadll can be loaded and functions could be called.

I just done a test for 'Version.dll' and a 'GetFileVersionInfoSize'Win32 APIfunction. The'Version.dll' was renamed to 'YesYCan.dll'.

Here is a screenshot of MS Depends utility with a Visual Studio Output window:

[Steven_L_Intel1]

Sergey,

What we're discussing here is a reference to the Intel-supplied libiomp5md.dll. Once an application is linked, the names of the DLLs it references are frozen - you cannot cause some other named DLL to take its place.

What exactly did you do other than renaming the DLL? Did you create an import library to link against or use a .DEF file? Sure, you can rename any DLL you want but that doesn't solve the problem being asked here.

[SergeyKostrov]

Quoting Steve Lionel (Intel)

...
What we're discussing here is a reference to the Intel-supplied libiomp5md.dll. Once an application is
linked, the names of the DLLs it references are frozen - you cannot cause some other named DLL to take
its place.

[SergeyK] Unfortunately, you're not considering some hacking techniquesused in some
companies. You know, that Microsoft's operating systems are full of bugs and
inconsistencies. Some of them are not fixed and won't be fixed at all because Microsoft
"declared" them as features.

...
What exactly did you do other than renaming the DLL?

[SergeyK] It is based on steps described inmy Post #1

Did you create an import library to link against or use a .DEF file?

[SergeyK] No. I "applied"a hack. Of course, a custom DLL with a custom Import library could
be created but it is a little bit longer way.

Sure, you can rename any DLL you want but that doesn't solve the problem being asked here.

[SergeyK] If a management would ask me to solve that problem I would solve it.I already
proved it in a simple test with a Microsoft's'version.dll'. But, I would resist to usea hackin
some legitimate commercialsoftware product that could be delivered to a customer. I would
convince everybody that this is not a good thing because the solution is based on the hack.

I also would like to tell that this is not a right solution when two DLLs for 32-bit and 64-bit
platforms are named identically. Ideally, it should look like:

for 32-bit ( Release )- DllName32.dll & DllName32.lib
for 32-bit ( Debug ) - DllName32d.dll & DllName32d.lib

for 64-bit ( Release ) - DllName64.dll & DllName64.lib
for 64-bit ( Debug ) - DllName64d.dll & DllName64d.lib

Best regards,
Sergey

[FengR]

Thank you so much Sergey and Steve. I will follow the hacking techniques.

And I second what Sergey's suggestions on DLL names. The target platform should be distinguished from the name of DLL files. Should not only depending on the "smartness" of Microsoft. :)