C_calls_Fortran USEDLL "MSVCR80.dll was not found"

[nflacey]

I'm new to ifortran and very rusty with Windows, has anyone seen this problem?

I'm trying to get the USEDLL example project to work. It compiles and links but doesn't execute, the following is displayed: "The application has failed to start because MSVCR80.dll was not found. Reinstalling the application may fix this problem."

I'm able to get USELIB to work.

I'm using VS Express and an eval copy of Intel Fortran 9.1 both downloaded last week (today is Sunday 5/20).

Compiled FSUB.F90 ifort /dll /Zi /D_DLL FSUB.F90 and then copied FSUB.dll and FSUB.lib to ..C_calls|FortranUSEDLLDebug.

Added path to FSUB.lib to Project ... Properties ... Configuration Properties ... Linker ... Additional Dependencies to get it to link

Thanks
Neil

[Steven_L_Intel1]

I would have thought that VC++ Express would install MSVCR80.DLL as a shared assembly. Try downloading and installing this and see if helps.

[John4]

I've seen that one a lot of times before.

The message about the application failing to start because MSVCR80.dll was not found, is usually triggered by a mismatch in the manifest files (or, when upgrading from VS2003 to VS2005, the fact that there might be no manifest files); it has nothing to do with MSVCR80.dll being actually missing (surely, it's in some folder within WinSxS).

So, checking that the libraries, /threads option, etc., are the same, should solve the problem.

If the MSVCR80.dll hadn't been installed, the message box should say "The application has failed to start because there is a mismatch in the Manifest file. Checking the library paths may fix this problem".

[Jon_D]

Hello,

I found this thread that seems to be dealing with the exact same issue I have been having.

I compiled an IVF Fortran dll that makes use of Fortran and C static libraries. Dependency Walker tells me that I am missing MSVCR80.DLL. A file search shows that I have several of this dll on my C drive. It is mentioned in this thread that upgrading from VS2003 to VS2005 might cause this problem. I did upgrade to VS2005 a few weeks ago.

How do I take care of this issue? This thread says:

"So, checking that the libraries, /threads option, etc., are the same, should solve the problem."

Where are these options located and what should they be same with?

Thanks,
Jon

[Steven_L_Intel1]

That's not the issue - that recommendation was suggesting that if your application consists of two or more projects that you make sure the run-time library setting is the same for all of them. But that does not cause the "missing" DLL problem.

Are you using this DLL on a system other than the one you built it on? See if installing the VC2005 Redistributables Package helps.

[John4]

If you upgraded from VS2003, make sure that the "Generate manifest" option is set to "Yes" (Project->Properties->Linker->Manifest file) and the "Manifest file" option is not empty (it should be something like $(TargetPath).intermediate.manifest).

John.

[Jon_D]

Steve,

The IVF DLL is on my machine where I compiled it. Installing VC++ redistributables didn't help. MSVCR80.DLL is still listed as missing. I also noticed that LIBMMD.DLL has some functions listed with "Unresolved Parent Import" sign. These functions are __powi4i4, __powr4i4 and __powr8i4.

John, thanks for the reply. I checked and "Generate manifest" option is already set to "Yes" and "Manifest file" option is not empty.

Jon

[Steven_L_Intel1]

Check the value of the PATH environment variable (Right click on My Computer, Properties, Advanced, Environment Variables to make sure it includes %IFORT_COMPILER10%IA32Lib

MSVCR80.DLL is provided by Visual Studio as a "shared assembly" and I can't figure out how you could not have the proper one on your system when you build. But try this.

Uninstall the Intel Visual Fortran Integrations into Microsoft Visual Studio
Download and install VS2005 SP1
Reinstall the integrations (or reinstall the compiler)

[Jon_D]

Steve,

Unistalling / reinstalling software didn't help. Any other suggestions?

Jon

[Steven_L_Intel1]

Did you install VS2005 SP1?

[Jon_D]

Yes, I did. I also noticed that I still have an intact folder for VS2003 under Program Files directory even though I thought I had uninstalled it. I also still have CVF 6.6C active on my machine. Might any of these be confusing VS2005?

Jon

[Steven_L_Intel1]

I noticed that you said that Dependency Walker complained that the DLL was missing. Have you downloaded a recent copy of Dependency Walker? The older ones don't understand manifest files.

Does the program not run? What is the exact message? The old directories won't matter.

[DavidWhite]

This issue also manifests itself (no pun intended) when distributing apps tousers without MSVS installed. You need to make sure that the same version of msvcr80.dll AND its manifest file are available on the user's machine, possibly best inthe app install folder.

Regards, David

[Jon_D]

Steve,

I downloaded the newest version of Dependency Walker and now I can see that MSVCR80.DLL is not missing. The new Dependency Walker shows a much more complicated module dependency tree than the old version I was using. Another module, MSJAVA.DLL is shown as missing but it is marked as "delay-load module" which I think won't cause a problem at run time.

Jon

[Steven_L_Intel1]

Correct. Do I gather that the program runs ok?

[Jon_D]

Well, that is the embarrassing part of the story. The DLL is being called by VB code which is being upgraded by another group. They haven't completed the work yet. And, this is the embarrassing part, I haven't yet figured out how to call a function within a DLL using Fortran. So, short story: I don't know if the DLL works. Maybe I will use this instance as an opportunity to figure out how to use DLLs in Fortran.

Jon

[Steven_L_Intel1]

Well that part is easy - just call the routine and link against the .lib generated when you build the DLL. Note that if you have created a DLL to be called by VB, you MUST specify the STDCALL calling mechanism for the routines. That means you'll also have to tell the Fortran caller that the routines are STDCALL - you'll probably end up doing something like:

!DEC$ ATTRIBUTES STDCALL,REFERENCE,ALIAS:"MyRoutine" :: MyRoutine

You could also study the VB-calls-Fortran sample provided and adapt it to your DLL.

[Jon_D]

Steve,

I got a chance to test my DLL that is being called from VB. What happens is if I use the debug version of the dll everything goes okay. If I use the release version I get an error at the first call to the DLL:

Unable to load DLL 'MyDLL.dll': The specified procedure could not be found. (Exception from HRESULT: 0x8007007F).

Dependency Walker shows that the particular function being called is indeed being exported. It lists warnings for the debug version of the dll but no errors. For the release version, it shows an error ("Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module."). I suspect that this error is due to LIBMMD.DLL which shows that __powi4i4, __powr4i4 and _powr8i4 functions are unresolved C functions.

Any ideas about how to fix this problem?

Thanks in advance,
Jon

[Jon_D]

Okay, I think I fugured the source of my problem. I have another software, Tecplot, installed on my computer which has libmmd.dll inluded in their Bin directory. My dll is linked against this dll rather the one listed in IVF's Bin directory. The version of Tecplot's libmmd.dll is 8.1.8.2 (and missing the required functions) whereas the IVF's is 10.0.10.2.

Now the question is: How do I force VS2005 to link against IVF's libmmd.dll?

Thanks,
Jon

[Steven_L_Intel1]

Ah, you have descended into "DLL Hell". It's not a matter of linking - one does not link to DLLs. Rather, it's which DLL Windows finds first when running the EXE. It generally follows this list:

1. Default folder
2. Folder containing the EXE
3. Folders on PATH, in order
4. Windows folder
5. Windows System folder

My advice is to delete (or rename) the copy of libmmd.dll in the tecplot folder - it's ok for it to use the newer one.

Theoretically, shared assemblies and manifest files solve this problem, but unfortunately they create other ones...