topic DependencyWalker, in Intel® Fortran Compiler

Redistributing Program with IMSL Routines

Bruce_Barker — Sat, 11 Oct 2014 00:41:07 GMT

I have a 32-bit VB-Net application that calls several FORTRAN dlls. The dlls work fine on the development computer and on a test installation computer (one without a compiler) with the exception of one dll that uses the IMSL library. The vb program can't find the dll with the IMSL routines. If I remove the IMSL calls, it works. I have the following statement in the code: include 'link_fnl_shared.h' and the following include library in the compiler settings: C:\Program Files (x86)\VNI\imsl\fnl600\IA32\include\dll.

I ran dependency walker and the routine is looking for a 64 bit version of IMS_DLL.DLL. When I include this in the program directory I get an error that says "An attempt was made to load a program with an incorrect format"

It seems I'm missing some redistributable file for the IMSL library.

DependencyWalker,

Steven_L_Intel1 — Sat, 11 Oct 2014 00:51:13 GMT

DependencyWalker, inexplicably, doesn't understand how WIndows deals with 32-bit and 64-bit applications on a 64-bit system. You want the IA-32 version of IMSL_DLL.dll. This should be in a folder on PATH - it won't work if it is in the folder with your DLLs. (Or it could be in the folder with the VB executable.)

Although you're using the 6.0 IMSL, I thought I'd mention an important issue should you upgrade to IMSL 7.01. The default for link_fnl_shared.h is now to link to a version of IMSL that also depends on Intel MKL, so you would need the appropriate MKL DLL installed as well. There is an alternative.h file, whose name I don't recall right now (and don't have a system with it installed), that uses an IMSL-only DLL. Note also that Intel Fortran doesn't add the MKL path to PATH by default - you'll have to do that manually.

Steve,

Bruce_Barker — Mon, 13 Oct 2014 15:38:31 GMT

Steve,

The VB program and DLL's are stored in the same directory so I placed imsl_dll.dll and imslmkl_dll.dll in the Windows\System32 directory which is on the system path. I'm still getting a DLL not found error message. (?)

You're missing the

Steven_L_Intel1 — Mon, 13 Oct 2014 18:28:46 GMT

You're missing the appropriate MKL DLL - you don't need both imsl_dll.dll and imslmkl_dll.dll. imslmkl_dll.dll requires mkl_intel_thread.dll, libifcoremd,dll, libmmd.dll, libifportmd.dll and libiomp5md.dll. All of these but the first are in the compiler redistributables installer.

If I'm interpreting your last

Bruce_Barker — Mon, 13 Oct 2014 18:57:00 GMT

If I'm interpreting your last message correctly, I don't need imslmkl_dll.dll. I deleted imslmkl_dll.dll and kept imsl_dll.dll and still the problem persists.

If you are developing all 32

mecej4 — Mon, 13 Oct 2014 19:33:00 GMT

If you are developing all 32-bit applications which are to be run on a 64 bit Windows system, c:\Windows\System32 is the wrong place into which to put 32-bit DLLs. Those DLLs should go to c:\windows\SysWOW64, if you have thought the issues through and you want system-wide access to those DLLs.

Whether to use imslmkl_dll.dll or imsl_dll.dll depends on how the application was linked, and the linking process is affected by #include <fnl...> directives in the source files.

My suggestion is to avoid using MKL completely until you have a working build/deploy routine. After that, you can incorporate MKL to achieve higher performance.

Did you resolve the 32-bit vs

Steven_L_Intel1 — Mon, 13 Oct 2014 20:00:31 GMT

Did you resolve the 32-bit vs. 64-bit DLL issue?

I moved imsl_dll.dll to the

Bruce_Barker — Mon, 13 Oct 2014 20:12:50 GMT

I moved imsl_dll.dll to the SysWOW64 directory and I'm still receiving a DLL not found exception. I also tried it in another directory in the system path and no luck.

SysWOW64 is not a place you

Steven_L_Intel1 — Mon, 13 Oct 2014 20:42:39 GMT

SysWOW64 is not a place you should put files. Keep in mind that VB will say "DLL not found" for ANY kind of DLL-related error, including entry point not found.

As an experiment, write a Fortran program linked to your DLL (which has a call to the routine, even if not executed) and run it from the same location as the VB executable. You should get more informative diagnostics.

Quote:Steve Lionel (Intel)

DavidWhite — Tue, 14 Oct 2014 00:36:40 GMT

Steve Lionel (Intel) wrote:

Keep in mind that VB will say "DLL not found" for ANY kind of DLL-related error, including entry point not found.

Note that VBA also behaves this way. It will also report DLL not found when a Win32 program tries to load an x64 DLL, even if it is on the PATH.

An error message that the DLL was not able to be loaded, rather than not found would be more useful.

I wrote a FORTRAN program

Bruce_Barker — Tue, 14 Oct 2014 18:56:50 GMT

I wrote a FORTRAN program that called the DLL and the error message said that msvcr71.dll was missing. With msvcr71.dll and imsl_dll.dll in the same directory as the VB program and DLL's it worked. I also discovered that msvcr71.dll is packaged with the Microsoft C Runtime Library 7.1 Merge Module. I was using Microsoft C++ 2008 SP1 Redistributable Package(x86), which apparently doesn't include msvcr71.dll. I switched to the Runtime Library 7.1 Merge Module and added imsl_dll.dll to the installer and now it's working. The target computer also has redistributables from w_cprof_p_11.1.072_redist_ia32.exe installed.

I am puzzled as to how you

Steven_L_Intel1 — Tue, 14 Oct 2014 20:42:25 GMT

I am puzzled as to how you had a dependency on such an old (VS2003) DLL but am glad to hear you got it working.