Could not open dll

[billfullcox_net]

H... I am using Windows 7, Composer XE with IMSL, VS2008, 64 bit. When I am in the debug mode, I get the message 'Could not open dll' after each compiled subroutine. Afterward, the program compiles, links and runs. I do not have this issue with the release (non-debug) mode. The libraries I am linking to are the following (if that is helpful):

"C:\\Program Files (x86)\\VNI\\imsl\\fnl600\\Intel64\\lib\\imsl_dll.lib"
"c:\\wint\\lib.i64\\winter.lib
"gdi32.lib"
"user32.lib"
"comdlg32.lib"
"winspool.lib"
"winmm.lib"
"shell32.lib"
"advapi32.lib"
"htmlhelp.lib"
I do not get this error with the 32 bit version of everything. Any suggestions?
Bill

[Steven_L_Intel1]

Please attach the buildlog.htm from the x64\Debug folder. Also, have you followed the instructions here to configure Visual Studio for IMSL?

[billfullcox_net]

I have followed the instruction for the IMSL. I have the same problem when using the debug without calling IMSL. Also, I am using the Winteracter environment even though I have VS2008. Attached is my build log.
Thanks in advance...
Bill

[Steven_L_Intel1]

This may be trying to open the message catalog which is a DLL. I am not familiar with the Winteracter development environment, but you would need to have the executable paths set up the same way as they are in Visual Studio. What have you told Winteracter the executable paths are?

[billfullcox_net]

Steve... I have been in contact with the Winteracter folks and they said they are using the VS2008 and Intel pathways, includes etc. The only hint I can come up with is that I have loaded the Compser XE over the version 11 of the Intel FORTAN.
If I know which dll's are called by the compiler, I can either include them in the pathways or stick them in the proper location.
Bill
PS. As a reminder, this is only happening with the 64 bit debug configuration and has occured right after I loaded the latest Composer XE with IMSL

[Steven_L_Intel1]

See if adding C:\Program Files (x86)\Intel\Composer XE 2011 SP1\bin\intel64\1033 to the list of executable paths helps. I am not certain that this message is coming from the compiler.

[billfullcox_net]

See next message

[billfullcox_net]

Steve...
I have tried your suggestion. I still get the "Could not open dll" message. The Winteracter folks assure me that it has to be in the compiler step. Any other suggestions?
It is also interesting that despite this message, the program compiles, links and runs.
Bill

[Steven_L_Intel1]

The compiler is looking for mspdbxx.dll, which resides in the Visual Studio Common7\IDE folder. This folder is part of the default executable path for builds within VS and when using the Intel compilervars.bat to establish the command environment. This folder needs to be added for Winteracter as well. Without it, you will have trouble debugging your application.

We will see about getting the error message improved.

[DAVID_M_Intel2]

So yes, that message should be "improved". Maybe it should be improved by making it go away. Otherwise it needs to be hooked up to come out as an honestly producedwarning or perhaps a comment.

This was originally there so that it would come out if our test systems were misconfigured as it would then cause the tests to fail. I wanted to make sure we were really testing the code from which this is spat out. The compiler can still produce debug info - it falls back to /Z7 instead of /Zi. You can get round the message by using /Z7 instead of /Zi - then it won't look for the dll at all.

BTW, the main disadvantage of /Z7 over /Zi is that it makes your object files bigger because they contain the debug info.

I had not anticipated that there was a useful user environment in which this message would be seen. Can you tell me more about why you don't have that directory in your path? How did you go about setting things up so that our compiler works but you don't have that in your path? I don't understand that well enough to be confident I can come up with a good solution for you without losing the ability towarn other users that they have a problem.That's the problem with making it a comment, of course - it would be unlikely anybody would ever see it, even if it would have been useful to them. If we make it a warning, you would still see it unless you took action to suppress it.

Thanks, David

[billfullcox_net]

Thanks David and Steve,
I do not know how it occurred and it only occurs in the pure 64 bit Fortran system. I have not played with any of the paths and I have used the default paths for all of the software. I tried to include the path that Steve suggested and the same event is occuring. What does remove the message is to use /Z7 during the compile. Otherwise, I do not have any other hints what is happening.
Thanks again.
Bill

[DAVID_M_Intel2]

I think that means the dll is not where we expect it to be. If you can find it and report back on where it is, that might be helpful to us. Perhaps we need to cater for that in the configuration. (also the exact version of VS would help so we can try to reproduce it) The Z7 branch does not use the dll so as long as you are ok with the larger object files, you should not encounter any other problems or limitations in functionality from using that rather than /Zi.

[DAVID_M_Intel2]

Incidentally, you are finding the 32 bit version or you would see the message there as well.

[billfullcox_net]

David,
The file mspdb80.dll resides in C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE and the version of VS I am using is Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM with Microsoft .Net Framework Version 3.5 SP1
I do appreciate the hep.
Bill