Different libiomp5md.dll versions

[Koenebaas]

Dear all,

I am buidling a DLL application that makes use of the Openmp library Libiomp5md.dll by specifying the /Qopenmp option. I am making use of the Intel® Parallel Studio XE 2017 Update 7 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2013, Version 17.0.0053.12, Copyright © 2002-2017 Intel Corporation. The corresponding Libiomp5md.dll is originating from 06 Oct 2016.

Now I am using this DLL together with an executable that also makes use of the Openmp library, but the program crashes as soon as the DLL is called. We suspect this is because the corresponding Libiomp5md.dll from the executable has a different file version (5.0.2015.922 instead of 5.0.2016.916). In the search path of the excutable the Libiomp5md.dll for the executabke is found first (rather than the one that comes with my DLL). Removing the /Qopenmp flag and rebuilding the DLL results in no crash and normal execution.

Since static linking of this library is not possible anymore, how can I make this work? Is it possible somehow to specify in Visual studio which version of the Libiomp5md.dll should be linked to? Any suggestions appreciated.

[Koenebaas]

Update:
The File version of Libiomp5md.dll from the DLL is 5.0.2016.916
The File version of Libiomp5md.dll from the EXE is 5.0.2015.922 (hence older rather than newer)

Why are these library versions not backward compatible?

[Steve_Lionel · Accepted solution]

There isn't really a way to force a specific DLL to be loaded along with your DLL. It's only the EXE location that Windows includes in its search list.

My suggestion is that when you install your DLL, you include the Intel redistributables installer that installs the latest DLLs.

[Koenebaas]

Thanks a lot for your hint Steve. My workaround is that I used the newest  Libiomp5md.dll also in the search path of the executable. Hence it seems that older code can still run with new intel omp libraries but not the different way around.

[LRaim]

Using this discussion for a question.

What about upward Intel Fortran DLL (libiom5md, libifcoremd, etc) compatibility ?
Is there any Intel statement about this problem ?

For example. If I have a large sw product, with more than one fortran .exe modules or .dll, developed along the years with different version of the Fortran compiler (could be v. 2016, 2017, 2018) can I include in the installation package only the most recent version of the redistributable Fortran dll (in this case v.2018) ? 

Regards

[Steve_Lionel]

The intention is that old Fortran code can link and run with newer libraries. The converse (new code and old libraries) is not supported. Barring unintended bugs, it is safe to install the latest redistributables.

This is not necessarily the case for other Intel products. MKL, in particular, has released incompatibilities in its libraries more than once. I don't think I ever encountered a similar issue with OpenMP, other than that Intel stopped providing the static libraries on Windows.

Unlike C/C++, Fortran objects let you defer to link-time which set of run-time libraries you're going to link against, which is why it's generally advised to build Fortran static libraries with the option to "disable default library search rules". This is not the case for C/C++, where the compiler emits different code for common library entities depending on the library option (/MT, /MD, etc.)