Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29236 Discussions

Missed dependency in IVF8.0 with debug multithreaded DLL

jeffrey_t_b
Beginner
765 Views
There seems to be a problem when selecting to use the debug multithreaded runtime DLL with Intel Visual Fortran 8.0 in Visual Studio .Net 2003. To duplicate, try:
  1. Start a Fortran Console app solution, and allow the wizard to include the main program sample code.
  2. Open the "properties" form for the new project.
  3. Select Fortran -> Libraries, and change "run time library" to "Debug Multithread DLL"
  4. Compile and run. The compile should go okay. Note the error, though, when running: The application has failed to start because MSVCRTD.DLL was not found.

Using the Dependecy Walker, the library that links to MSVCRTD.DLL is "libifcoremdd.dll".

This is a fresh installation of Windows XP. I suppose if it the machine had a previous version of Visual Studio or CVF, then the msvcrtd.dll library would have been there. Is it okay to just copy msvcrtd.dll from another machine? Am I asking for trouble if I do that? (Visual Studio 2003 has a newer version of the debug multithread DLL runtime... Shouldn't that be used instead?)

Thanks in advance for any thoughts on this issue.

Jeff Borlik

0 Kudos
3 Replies
Steven_L_Intel1
Employee
765 Views

It's not "missed". Things you build against the Debug DLLs are not transportable to systems where Visual Fortran is not also installed. Note that you would have had to manually copy libifcoremdd.dll - and the REDIST.TXT file provided with the product says that this is NOT one of the redistributable files.

MSVCRTD.DLL is Microsoft's version of this - a non-redistributable debug version of the MSVC run-time library DLL.

The license agreement does not permit you to copy these DLLs. If you're going to run on another system, be sure to do a "Release" build, or at least specify the non-debug DLLs.

0 Kudos
jeffrey_t_b
Beginner
765 Views
Steve -
Thanks for the quick reply. I apologize for not being clear... The problem is not with deployment, but rather on my development machine. I do not have msvcrtd.dll on my development machine, which is a freshly-installed WinXP box with only Visual Studio .NET 2003 and IVF 8.0.
If I had to guess: This isn't a problem for most people, because they have installed other programs (such as older versions of the compilers) that automatically install msvcrtd.dll. But glancing around through this forum, I can see at least one other post dealing with a similar issue (titled "Math libraries incompatible with VC7.NET?" from "midlandvalley":http://softwareforums.intel.com/ids/board/message?board.id=16&message.id=630&highlight=msvcrtd.dll#M630).
- Jeff
0 Kudos
Steven_L_Intel1
Employee
765 Views
Oh, yeah. Sorry for the incorrect answer.
We recognized this problem after 8.0 shipped and expect to have it solved for the next release. The problem is that MSVCRTD.DLL is supplied by MSVC6, which is what the DLLs are built with. Microsoft changed the name of this DLL in VC.NET 2003 and AGAIN in VC.NET 2003. Apparently, everyone who tested this also had MSVC6 installed....
The use of the debug DLLs was inbtroduced in CVF because of problems with mixed Fortran-C applications - people building these would get "multiple C library syndrome" because MSVC linked against MSVCRTD by default, and CVF was using MSVCRT.DLL.
We spent quite a bit of time trying to figure out an appropriate solution that didn't cause more problems that it solved. If I recall correctly, we'll be supplying DLLs that statically link in the used parts of the MSVC library, ending the dependency on the MSVC DLLs. As long as programs don't try things such as allocating memory in Fortran and freeing it in C, it should be ok. There were a few other wrinkles we discovered that are being ironed out.
For the time being, I'll suggest selecting the non-debug DLLs under the Libraries property attributes. I haven't tried this, but what you may want to try is make a copy of MSVCR70D.DLL and call it MSVCRTD.DLL, then put it in your WINNTSYSTEM32 folder. This may actually work.
0 Kudos
Reply