Distribute DLLs to IT-restricted customers

[CoryG]

We build software using the Intel Fortran Compiler and distribute it to various customers. Until recently, we've been using the 2013 compiler version. Along with our executable, we ship out libiomp5md.dll as our code needs this to run.

Recently, we've upgraded to the latest version of the Fortran Compiler. This has caused issues with accessing that DLL on some customers' computers. Even if we ship out the latest version of libiomp5md.dll with our executable, the code cannot run. I was able to fix this for one customer by having them upgrade the Intel runtime libraries (as suggested in this post: https://community.intel.com/t5/Intel-Fortran-Compiler/Procedure-entry-point-kmpc-aligned-alloc-could-not-be-located/m-p/1330222 , which, by the way, describes the exact same errors our customers were getting).

Unfortunately, a lot of our customers have IT systems that are pretty locked down, and so having everyone upgrade the Intel runtimes would be hard. Even without IT issues, forcing all customers to do this manually would be a pain. Is there a simpler way to make sure that when we ship out our executable the correct DLLs will be present on the receiving end?

[Steve_Lionel]

When you say "the code cannot run", exactly what do you mean? What are the error messages?

There are multiple DLLs that are used by Intel-compiled applications. You could choose to link against the static libraries, which will reduce many of the dependencies, but not all - in particular, libiomp5md.dll. You can use the Dependencies app to identify which DLLs your program needs.

[CoryG]

We get errors like:

"The application was unable to start correctly (0xc000007b). Click OK to close the application."

"The procedure entry point __kmpc_aligned_alloc could not be located in the dynamic link library C:\..."

So is there not a static library we can use instead of libiomp5md.dll? Would there be a simple way to remove the need for this DLL? Our code uses OpenMP pretty extensively, but I'm not sure what functionality requires that particular DLL.

[Steve_Lionel]

That's an OpenMP library entry point. On Windows there is no longer a static Intel OpenMP library (this change happened about 8-10 years ago - oddly, Intel continued to ship a static OMP library on Linux, though I don't know if they still do.) 

As that entry point has been in libiomp5md.dll for years (I found it in a 2021 copy), it makes me wonder which copy of this you are shipping. Make sure that you are providing the 32-bit or 64-bit version, depending on your application build configuration.

[CoryG]

I downloaded the Dependencies app, and it is showing the dependency on libiomp5md.dll. It lists on there a specific file location for the DLL. If I grab the DLL from that location and ship that, I should be fine right?

How would I check which version the DLL is?

[Steve_Lionel]

All DLLs have a version that is visible when you look at the file properties. If your program runs fine on your system, then, sure, ship that DLL, which you would place in the same folder as the executable.

[CoryG]

That worked! I've read elsewhere on the forum though that it's not best practice to distribute DLLs. Instead, it's better to rely on end users downloading the runtime libraries. Why is that?

[Ron_Green]

"Why" - the Runtime Libraries installer has all the libraries possible.  So you don't accidentally forget to package one or another.

The latest Runtime Libraries have all the most recent fixes, including security fixes.  And the latest libs are backwards compatible.  

BUT

to save size, if you only need the OpenMP runtime libiomp5.dll and compiled with -static-intel you can easily package libiomp5.dll with your binary.  

And as you said, installing the Runtime Libraries may involve a headache with yout IT department who may not be keen on installing "unknown" files from a vendor. 

[CoryG]

Makes sense. Thanks!

[andrew_4619]

One other reason people stick a load of dlls with the exe and then include the folder in the path. If this path occurs before other runtime paths it can right royally foobah other applications that use any of those dlls. It can causes endless  of pain when least expected....

[Steve_Lionel]

And even worse is when the application's installer puts the DLLs in the WIndows System folder, where they don't belong. I can't count the number of times I helped users resolve a problem caused by some third-party tool copying Fortran support DLLs to the Windows System folder.

[CoryG]

But if we just have the DLL in the same folder as the executable and don't mess with the PATH variables or anything, we should be good, right?

[Steve_Lionel]

Yes, that is the way.

[CoryG]

Sweet. Thanks for all the help!