manifest file selects msvcr80.dll version 8.0.50727.4053 which causes a file not found error

[Greg_T_]

Hello,

How does the Fortran compiler select which version of the msvcr80.dll as a dependency?

A Fortran DLL compiled on one computer that is distributed to other computers has given a "myname.dll not found" at run time. The dependency walker utility shows that the msvcr80.dll dependency in question should have version 8.0.50727.4053, which apparently comes from a recent Microsoft Visual C++ 2005 Service Pack distribution (July 28, 2009): http://support.microsoft.com/kb/973544
That particular msvcr80.dll is found in a windows side-by-side sub-directory (c:\windows\winsxs\...). The other computer had a slightly older version of the msvcr80.dll, so it didn't run. The Fortran DLL manifest file lists the msvcr80.dll and the specific version number.

We're working on obtaining the latest vcredist_x86.exe to include in our installer package so that this latest msvcr80.dll version will get installed. The short-term work-around was to compile the Fortran DLL on a computer with a little older msvcr80.dll.

Would it be better to turn off he manifest file? Would that avoid a dependency of the Fortran DLL on a particular version of the msvcr80.dll? Or are there other negative effects of turning off the manifest file in the project options?

Is there a way to avoid the Fortran DLL being dependent on such a particular version of a dependency DLL? Any other suggestions that would improve how the Fortran DLL is compiled and distributed as part of a larger program? Let me know if more information would help.

Thanks for your help.

Regards,
Greg

[Steven_L_Intel1]

The Fortran compiler itself hasn't the foggiest notion of msvcr80 dependencies. What happens is that when you link against the DLL libraries, a dependency on the specific version of msvcr80.dll as provided in the MSVC LIB folder's corresponding import library is created. If you then take your EXE or DLL to another system that doesn't have that specific version installed, you'll get this error.

If you turn off manifests, you'll then have to provide a copy of msvcr80.dll along with your application. Typically, application developers add Microsoft's merge module for the MSVC libraries to their own install. Microsoft installs their merge modules under C:Program FilesCommon FilesMerge Modules. You can see here for further reading.

Another possibility, which may or may not be appropriate depending on how your application is to be used, is to link against the static libraries, eliminating DLL dependencies.

[Greg_T_]

Quoting - Steve Lionel (Intel)

The Fortran compiler itself hasn't the foggiest notion of msvcr80 dependencies. What happens is that when you link against the DLL libraries, a dependency on the specific version of msvcr80.dll as provided in the MSVC LIB folder's corresponding import library is created. If you then take your EXE or DLL to another system that doesn't have that specific version installed, you'll get this error.

Hi Steve,

Thank you for the information and the link. We do like using DLLs since we have a mixed-language software, where Fortran DLLs do the computations. It is good to know that it is the linker that is adding the msvcr80 dependency. And it sounds like we'll keep the manifest file on, since it helped track down this dependency problem.

A reply from Microsoft support suggets there may be a way to set a link option to use a "generic" version of the msvcr80, rather than the most recent one by default. It also sounds like the most recent msvcr80.dll was part of a security "hot fix", but it is not yet available in the C++ redistributable package that we include in the install script.

Is there a way or an option in Visual Studio to specify that a certain msvcr80.dll should be the one used when linking the DLL?

You mentioned the MSVC LIB import library; is there a way to modify that to use a different msvcr80.dll?

I've looked through the project configuration properties/Linker options, but haven't found any option like that. Thank you for your help.

Regards,
Greg

[Steven_L_Intel1]

The only way I know of to select a "generic" MSVC DLL is to turn off use of manifests. This would require you to provide msvcr80.dll alongside your application. You could also create your own manifest that named a specific version of the DLL you want to use - I think. I have no specific experience with manifests other than a cursory glance at the MSDN documentation. I've seen others run into the problem you describe and it is annoying.

[tenuti]

Quoting - greg_thorwald

Hello,

How does the Fortran compiler select which version of the msvcr80.dll as a dependency?

A Fortran DLL compiled on one computer that is distributed to other computers has given a "myname.dll not found" at run time. The dependency walker utility shows that the msvcr80.dll dependency in question should have version 8.0.50727.4053, which apparently comes from a recent Microsoft Visual C++ 2005 Service Pack distribution (July 28, 2009): http://support.microsoft.com/kb/973544
That particular msvcr80.dll is found in a windows side-by-side sub-directory (c:windowswinsxs...). The other computer had a slightly older version of the msvcr80.dll, so it didn't run. The Fortran DLL manifest file lists the msvcr80.dll and the specific version number.

We're working on obtaining the latest vcredist_x86.exe to include in our installer package so that this latest msvcr80.dll version will get installed. The short-term work-around was to compile the Fortran DLL on a computer with a little older msvcr80.dll.

Would it be better to turn off he manifest file? Would that avoid a dependency of the Fortran DLL on a particular version of the msvcr80.dll? Or are there other negative effects of turning off the manifest file in the project options?

Is there a way to avoid the Fortran DLL being dependent on such a particular version of a dependency DLL? Any other suggestions that would improve how the Fortran DLL is compiled and distributed as part of a larger program? Let me know if more information would help.

Thanks for your help.

Regards,
Greg

It seems I incurred in the same issue. What's the real fix for this?

Do I need to uninstall some Microsoft Visual Studio C++ 2005 Service Pack distribution or some specific KB?

You told that you are using your short term workaround using a little older msvcr80.dll. How many files do I need to swap and where can I find those little older files? Maybe only the files placed here?

C:Program FilesMicrosoft Visual Studio 8VCredistx86Microsoft.VC80.CRT

In case of rebuilding all the Fortran DLLs without manifest files, is it only needes to activate the build flag /MANIFEST:NO?

[Greg_T_]

Hello tenuti,

It is interesting to know that someone else has encountered this problem with the msvcr80.dll. We think that it was installed as part of a Win64 hotfix, possibly done automatically by our IT service to keep our computers up to date.

I am still using the work-around of compiling my Fortran DLL project on an older computer that does not have that particular msvcr80.dll version. That is not a very satisfying fix, and certainly not a long-term fix. We are hoping that Microsoft will release an updated Visual Studio (VS) redistribution package with the updated msvcr80. But as of now, we have not yet obtained an updated VS redistributable. If you find one, I would sure like to know.

I have not yet had a chance to try Steve's suggestion to turn of the manifest file. Have you tried that, and if yes does it avoid the problem?

Regards,
Greg

[Steven_L_Intel1]

It looks as if Microsoft created a big batch of trouble here. See this blog post for one users rant, with some suggestions for solutions. See also this Slashdot story, though it is largely content-free.

[Greg_T_]

Quoting - Steve Lionel (Intel)

It looks as if Microsoft created a big batch of trouble here. See this blog post for one users rant, with some suggestions for solutions. See also this Slashdot story, though it is largely content-free.

Hi Steve,

Thank you for the update and links. It looks like the updated vcredist_x86.exe C++ 2005 SP1 redistributable package is working well for us. We obtained from this Microsoft web page.

Initial testing of our software install is working well using this redistributable, with more testing still to do.

Regards,
Greg

[tenuti]

Quoting - greg_thorwald

Hi Steve,

Thank you for the update and links. It looks like the updated vcredist_x86.exe C++ 2005 SP1 redistributable package is working well for us. We obtained from this Microsoft web page.

Initial testing of our software install is working well using this redistributable, with more testing still to do.

Regards,
Greg

Hello Greg,

I didn't try the suggestion to disable manifest files. We opted to uninstall some KBs installed automatically by IT team on our build machine and we were able to compile again our FEM solver DLL's suite. We will try soon your new updated information in order to getting the machine updated with all the Visual Studio patches and KB fixes and making a well working set of binaries.

[Michel]

Quoting - greg_thorwald

Hi Steve,

Thank you for the update and links. It looks like the updated vcredist_x86.exe C++ 2005 SP1 redistributable package is working well for us. We obtained from this Microsoft web page.

Initial testing of our software install is working well using this redistributable, with more testing still to do.

Regards,
Greg

You can tell the linker to include a version number of the needed runtime DLL with this linker switch
/manifestdependency:"type='win32' name='Microsoft.VC90.MFC' version='9.0.30729.1' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'"
And a line for 'Microsoft.VC90.CRT'
I include the runtime 2008SP1 installer in the client install package.

It is a pain to try to not use manifests or put the runtime DLLseverywhere in your app dirs.

Michel.

[newfortranuser]

Quoting - greg_thorwald

Hi Steve,

Thank you for the update and links. It looks like the updated vcredist_x86.exe C++ 2005 SP1 redistributable package is working well for us. We obtained from this Microsoft web page.

Initial testing of our software install is working well using this redistributable, with more testing still to do.

Regards,
Greg

Greg, et al.

Thank you for sharing your expereince. I am grateful to have found this thread, because I believe we have the same problem. The affected MS libs are MFC80.dll, MSVCR.dll and MSVCP.dll in our case. We are using Visual Studio 2005 SP1 and, like you, found that the C++ wrapper for our mixed language application was expecting version 8.0.50727.4053 -- which is present only on our development machines.

Yet I could not understand is why installing the VS2005 redistributables did not fix our problem. Your discovery that the VS2005 redistributable is out of date -- which is quite surprising! -- seems like a perfect explanation. Even so, when I installed the VS2005SP1 redistributable (which I found before reading your post) it did not help! And in fact, a search of C:WINDOWSWINSXS (and indeed the whole of C:) turns up serveral older versions of the suspect DLLs but none of version 8.0.50727.4053. So I am suspicious that the installation of VS2005SP1 redist did not work as intended. Based on your detailed report, I will try again.

Thank you, Steve and everyone who has contributed to this thread.

NFU