Issue with distribution of software that uses OpenMP

[Jon_D]

I have a VB.NET application that uses a Fortran dll which itself utilizes OpenMP parallelization. I compile the Fortran dll with Fortran 2016 Update 4, install the application on the target machine along with my Fortran dll and libiomp5md.dll that comes with the 2016.0.4 compiler, and everything works fine.

Then, I do the same thing but this time I compile the Fortran dll with 2017.0.2 compiler and distribute it with libiomp5md.dll that comes with that compiler, and the application on the target machine complains that it cannot find my Fortran dll.

The same application works fine on my machine regardless of the Fortran compiler I use. So I think that the application is able to find a dependence that exists on my machine but not on the target machine when 2017.0.2 compiler is used. dumpbin tells me that my Fortran dll depends on libiomp5md.dll, kernel32.dll and imagehlp.dll which all exist on the target machine.

My questions are: Did something change from Fortran compiler 2016.0.4 to 2017.0.2 in terms of OpenMP implementation? Are there any compiler flags to be re-adjusted? Or is there anything I can check to figure out why I am having this issue?

Any help will greatly be appreciated.

Jon

[Steve_Lionel]

Where do you put libiomp5md.dll? It won't be found if you put it alongside your Fortran DLL.

Better would be to install the Intel compiler redistributables on the target system.

[Jon_D]

Yes, I put it where I put the Fortran DLL and the VB.NET executable under the Program Files by default. This has worked through multiple versions of the Intel Fortran compiler until version 2017.0.2. I am curious why it works with Fortran 2016 but not 2017.

Thanks!

[Steve_Lionel]

When VB.NET can't find an entry point in a DLL, it confusingly tells you it can't find the DLL. Please show the "library" declaration for the routine in VB and attach a ZIP of your DLL or a Dependency Walker .dwi file for the DLL (Open DLL with Dependency Walker, select FIle > Save as.)

It could possibly be that the "decoration" of the external name changed between versions due to a bug fix. There have been issues like that in the past where the compiler incorrectly decorated the name.