Fortran dll (+imsl) running only with VS+Intel Visual Fortran installed

[Gustavo_B_1]

Program calling fortran compiled dll (using IMSL functions) runs on machine with visual studio and intel visual fortran installed. On other machines does not work (cannot access the fortran dll, exception HRESULT: 0X8007007E). We suspect something to do with libraries not installed in those other machines (dependency walker indentifies LIBIFCOREMD.DLL, LIBMMD.DLL, LIBIFPORTMD.DLL, MSVCR100D.DLL, LIBIOMP5MD.DLL that seem to come with the IDE) . Just copying those dll files in those machines not working. Any idea: ¿another compilation options or link to IMSL?¿installing/registering those missed dll files in windows?¿how?...

Thanks in advance for any suggestion.

Gustavo

[TimP]

Without the use of the redistributables package, you would need to set up PATH yourself to include the .dll you copy over.  For an initial test, putting them in the same folder with the .exe should work.    They come in both 32-bit "ia32/x86" and 64-bit "intel64/x64" versions; you need the choice which matches your .exe.

msvcr100d.dll should be found in  visual studio 10 (VS2012) redistributable package; the others would be in the Intel redistributable which corresponds with your compiler. 

[Steven_L_Intel1]

MSVCR100D.DLL is not copyable. You need to build a Release configuration and then install the Visual C++ 2010 redistributable installer from Microsoft.

[Gustavo_B_1]

Dear Tim and Steve.

Thanks for your answers, we'll try along the day. Let me just explain our constraints. We have some dozens of engineering tools like this one we try to build with VS+Intel IDE, placed in a server in an intranet with about 100 of potential users. Some/many tools may need fixes and improvements througout the year. Current versions were built with Compact Visual Fortran. Still no one calling IMSL functions updated to Intel. The instalation procedure for each tool in our intranet cannot be more complex than just copying the executable files (and libraries?) in that server. We may accept one special common instalation per year in those 100 machines running these tools, but NOT each time we make changes in one of the tools.

 Thanks again for your support. I'll confirm if your suggestions works.

[mecej4]

Gustavo,

Note that, if you plan to distribute applications containing IMSL code to others, and that IMSL code comes from libraries in the IMSL package marketed by Intel for use with Intel Fortran, you may need to obtain deployment licenses for every one of your clients. There was a change in the IMSL licensing during the last couple of years; earlier versions of IMSL from Intel and Compaq did not require deployment licenses.

Please see: http://software.intel.com/en-us/articles/imsl-licensing-frequently-asked-questions

With that background, it is reasonable to ask: Which IMSL routines do your applications call?

[Gustavo_B_1]

Tim, Steve...

Thanks, it seems it works using the redistributable installer of Visual C++ coming from a release configuration.

mecej4...

I made a technical question. But don't worry, we do not intend to violate any license agreement. Regarding the IMSL routines called by our tools, it is not possible to give an answer now. First versions of some of our tools were writen in the 80's. I guess we will have to check dependencies each time we migrate one from Compaq to Intel. Why? What was going to be your proposal?

[mecej4]

Gustavo B. wrote:

I made a technical question. But don't worry, we do not intend to violate any license agreement.

The reason that I highlighted the licensing issue is that there was a major change in Intel/IMSL licensing policy between IFort-11/IMSL-6 and IFort-12/IMSL-6a, which propelled many users, especially those whose code used a small number of IMSL routines, to consider freeing their codes from the bonds to IMSL.

Regarding the IMSL routines called by our tools, ... I guess we will have to check dependencies each time we migrate one from Compaq to Intel. Why? What was going to be your proposal?

There may be MKL routines and other sources (open-source, other libraries) that could be used instead of the IMSL routines. MKL is not as comprehensive as IMSL, but its coverage is steadily expanding. For instance, if you need statistical routines, there is a good chance that a current version of MKL already provides those.

[Gustavo_B_1]

Ok, thanks. We indeed are considering alternatives to IMSL for new developments. But we are attached to IMSL in our old tools. Analysing all that code and replacing those calls to IMSL by calls to other libraries, or by our own code in the most simple cases, is not feasible for us at this time.