Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

MSVCR90.DLL was not found

ferrad01
Beginner
2,010 Views
I have a simple small DLL which has building with a batch script just fine for a month now. However when I try to build it today depends says it needs MSVCR90.DLL, which for some reason the executable which loads this DLL cannot find. Why it cannot find it is another issue (I have VS 9.0 / Intel 11.060 installed).

But my main question is why was the DLL created yesterday depending on MSVCRT.DLL while todays depends on MSVCR90.DLL?

depends done on yesterday's DLL:

USER_KINETICS.DLL
LIBMMD.DLL
KERNEL32.DLL
MSVCRT.DLL
KERNEL32.DLL
NTDLL.DLL
KERNEL32.DLL
NTDLL.DLL

depends done on today's DLL:

USER_KINETICS.DLL
LIBMMD.DLL
KERNEL32.DLL
MSVCR90.DLL (which it can't find)
KERNEL32.DLL
NTDLL.DLL

Files attached. Yesterday's result of a buildall is in USER directory. Today's result of a buildall is in the USER\\NEW directory.
0 Kudos
14 Replies
TimP
Honored Contributor III
2,010 Views
msvcr90.dll should be present in the visual studio 9.0\vc\redist\ (both 32- and 64-bit versions, if you installed X64). Changes like this, with the necessary directories under \redist\ not coming automatically on PATH, are likely to happen if you change your project setting from static /MT to dynamic /MD, and can be particularly annoying if you don't clean everything when changing the setting. Note Steve's posts about the defaults for C and Fortran not matching.
0 Kudos
ferrad01
Beginner
2,010 Views
msvrc90.dll is present on my c drive in a few Winsxs places. There are 2 issues here:

1. Why can't my dll find msvcr90.dll? That's an issue I need to focus on later, but my main problem is:

2. Why is my build now looking for mscvr90.dll when yesterday it was looking for msvcrt.dll (and was happy as it found it)?

Adrian
0 Kudos
Steven_L_Intel1
Employee
2,010 Views
None of the files in the "redist" folder are supposed to be referenced - that folder is for your convenience in locating DLLs to be copied to other systems.

MSVCR90.DLL should be referenced through a manifest, in the shared assembly. You won't find the file by exactly that name. I spent a bit of time on your issue and could reproduce it on my system, building from the command line. I know that if you build from VS, it runs the Manifest Tool that embeds a manifest pointing at the shared assembly. You may have to run mt yourself.

As to why things changed, I'd have to guess that "yesterday" you were linking against a different set of libraries. There's nothing in the ZIP you provided that offers a clue on that.

I had to go look up some of the switches you used - this must be old PowerStation code. /Qfpp1? /LD? Which language calls this DLL?
0 Kudos
ferrad01
Beginner
2,010 Views
Thanks for the info. You say you reproduced the problem: did you create a DLL which depends on MSVCR90.DLL, and that depends.exe cannot find? If so, did you solve the problem? My colleague performed the exact same build as me (on his machine), and depends.exe found the DLL just fine. I'm not sure what settings I need to change on my machine to allow MSVCR90.DLL to be found.

Just before I left the office yesterday, I started a reinstall of VS2008. I won't get a chance to check if that works until June 7 though. I'll probably reinstall IVF 11.1.060 as well.

Yes this code and build process is quite old. It is Fortran all the way through.

Adrian
0 Kudos
mecej4
Honored Contributor III
2,010 Views
Just a thought, one that may help as a stop-gap measure until you get the MSVCR90.DLL issue sorted out:

You can add /MANIFEST:NO to the linker flags.

0 Kudos
Steven_L_Intel1
Employee
2,010 Views
Yes, I simply built the DLL and depends could not find the DLL - which I sort of expected. Unless you use MT.EXE to embed the manifest, Windows has no idea how to find a shared assembly. Using /manifest:no would require you to copy MSVCR90.DLL from the redist folder into where Windows can find it, but this is not the method I would recommend.

Restating - the way Microsoft wants you to do this is with manifests. Reinstalling VS or IVF will not help.

I did not have enough time to work through a solution - which is likely to run mt.exe to embed the manifest. If you build a DLL in Visual Studio and look at the build log, you'll see what it does. You can then add the commands and options to your command line build. You can read more about manifests at msdn.microsoft.com

I will try to get back to this next week, if you haven't figured it out by then.
0 Kudos
ferrad01
Beginner
2,010 Views
I'm pleased that you can reproduce the problem. But this is the method I have used to build DLLs for some time, shouldn't this just work? Like it does for my colleague next door? There must be some setting I need to do on my machine to get the built DLL to find the RT DLL's it needs.
0 Kudos
Steven_L_Intel1
Employee
2,010 Views
I don't know enough about your environment to know why it does/doesn't work. Offhand, I'd say no, it shouldn't work with VS2003 (2005?) or later.
0 Kudos
ferrad01
Beginner
2,010 Views
I'm not sure what you mean that it shouldn't work with VS2008. Isn't Intel Fortran 11.1 tested under VS2008 build environment? Why doesn't Intel VF 11.1 work with VS2008? or VS2005 for that matter?
0 Kudos
Steven_L_Intel1
Employee
2,010 Views
I mean it shouldn't work because when you're referencing a shared assembly, embedding the manifest is required. You're not doing that.

Add this line to your .BAT, after the ifort command that does the link:

mt.exe /nologo /outputresource:user_kinetics.dll;#2 /manifest user_kinetics.dll.manifest

What this does is take the manifest created by the link and embed it in the DLL using resource #2 (for a DLL, this is always #2 - for an EXE it would be #1.)

The version that "worked" was linked using a VS2003 environment, which did not use shared assemblies.

I also recommend removing the "/link /nodefaultlib:library /nodefaultlib:libc.lib" from the ifort command. - you don't need these.

Some general reading on how manifest files are used can be found here.
0 Kudos
ferrad01
Beginner
2,010 Views
Thanks Steve, I will check this out when I get back on June 7.
0 Kudos
ferrad01
Beginner
2,010 Views
Steve,

I added the mt.exe line to my batch file, but I still get the error from depends that it can't find MSVCR90.DLL.

So I tried generating the project from scratch- this should work out the box, right?

I created a new project DLL from VC2008, please see attached dll1.zip. I built the DLL, and ran a depends, which shows it still can't find the MSVCR90.DLL

Now this should work, do you know what the problem is?

Adrian
0 Kudos
Steven_L_Intel1
Employee
2,010 Views
You changed some settings in the project - in particular, you set "Use Manifest" to No. That will cause the problem.

Adding the MT line worked for me. What does your new .bat look like?
0 Kudos
ferrad01
Beginner
2,010 Views
It works now, turns out I was using an older version of depends that didn't know about SxS
Thanks for your help,
Adrian
0 Kudos
Reply