Is there a document somewhere that explains everything about building and distributing a console program that uses IMSL? We have sent our program to a user, and he can't run it because of missing DLL's.
We are using Composer XE 2013 and the IMSL that we bought along with that.
It could be that part of our problem is that we recently changed INCLUDE 'link_fnl_STATIC.h' to INCLUDE 'link_fnl_shared.h' as a workaround for another problem.
It's like any program that links to shared libraries - you need to distribute the necessary run-time DLLs. For an Intel Fortran application that use IMSL, this will include the Intel Fortran redistributables, an MKL DLL and imsl_dll.dll, plus an MSVC redistributable for the version of Visual Studio you used. Dependency Walker is a good way to identify which DLLs you need.
Thanks, Steve. I'm digging my way through Dependency Walker output. It is telling me the code needs a file named BINLIB.DLL, and I do have a file by this name, but not the source, and I don't where it came from or where it being used in the program. I expected doing a solution wide search for "binlib" would find something, but it didn't. Is there a way to find where this ties into my project?
If it is shown as a direct dependency of your executable, then what I would do is set the project linker property General > Show Progress > Show Some Progress Messages and relink. Scan the build log for mentions of BINLIB.LIB (which is how it would get linked in) and see which object module adds a reference to that, assuming it isn't mentioned explicitly in the "Additional dependencies" list.
I relinked with that setting turned on, but I don't see anything that hints where anything is beiing called from. Did I do something wrong? The buildlog is attached. Maybe I just don't know how to read the thing. But BINLIB only appears in 4 places.
I'm going ot try removing the file, and see if unresolved externals tell me something.
The program would link with BINLIB.DLL removed, but the EXE won't run because it says that file is missing. I don't know what that means. This file is not in the list of formal Dependencies in Visual Studio.
binlib.dll isn't used at all in linking. From the build log, it looks as if binlib.lib has been added as a "source file" in the project, or maybe under Additional Dependencies.
Thanks for pointing that out. I scoured through the project list and I found binlib.lib buried in a subfolder. When I exclude it and relink, I get the unresolved externals that tell me what's being called and where from. In this particular case, it appears to be code for reading data files generated by ANSYS.
After more poking around, I found what I think is the source code from which binlib.DLL was built. It's definitely code from the ANSYS company. I tried feeding it to Intel Fortran, but that didn't get too far. Before spending time trying to update this, I need to find out if we still need it.
By searching the web, I found this link: http://www.ansys.stuba.sk/html/prog_55/g-int/INS2.htm . That page states that ANSYS supplies the DLL and the associated import library. If the compiler used by ANSYS did not produce code that is compatible with the compiler that you are now using, you may need to request the vendor of ANSYS to furnish you with new/compatible versions of BINLIB.LIB and BINLIB.DLL.
Thanks, mecej4. That is good information. I think someone who worked on this project about ten years ago added the ANSYS stuff to use in his graduate research work. If I can determine that no one is using it, I will take it out.\
The folder that I found containing the source files also has .dsp and .dsw files, probably from Compaq fortran. I tried importing this into Intel Fortran, but didn't get very far trying to build it. Before spending any time on fixing this, I will find out if it is still needed.
If the Ansys DLL and import library were distributed for use with CVF (Compaq Visual Fortran), the routines in them probably use the Stdcall linkage. In that case, they may or may not be usable with Intel Fortran.