- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recently upgraded from Intep Fortran 11 to Composer XE. I am working on a project that uses a couple of Fortran built DLLs inside of a Fortran program, all built with this compiler using VS2005, all part of the same solution. The problem happened when I upgraded my compiler. When I did that, I found that this project I had been working on would no longer compile in debug mode...it is giving me the LNK2005 error. When compiled in Release mode it links fine, but when I go to run it I get the MSVCR80.dll not found error. This is espcially frustrating because I have not modified any aspect of the build environment other than updating the compiler. Recompiled everything, ensuring that I am using the multithread DLL versions for the DLLs, and I've tried diabling the matrix multiplication call library I had heard can cause problems, all to no avail. I've even tried commenting out all of the calls to load or use the DLLs, but I still get the same errors. Any fresh ideas would be greatly appreciated!
Link Copied
12 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Perhaps VS2005 is corrupted. I would suggest uninstalling and reinstalling Visual Studio.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
msvcr80.dll should be present under visual studio 8\VC\redist\x86\ and (if you installed X64) \VC\redist\amd64\. I'm not having any success in getting ifort to want to link against it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A little but more info...If I move the mscvr80.dll into the directory with the release version of the executable (making sure it is available) I get a runtime error R6034 - "application has made an attempt to load the C runtime library incorrectly"...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That does look like the file may be corrupted. I would run disk check and replace the .dll from a reliable source (such as the VS2005 install package).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aaah, the upgrade train...I've upgraded to VS2010, and re-connected the compiler to work with VS2010, and I am still having that same problem...It is looking more and more like a compiler issue. My next option I suppose is to down-grade back to IF 11 and see if that fixes this issure...anybody have another idea?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
LNK2005... you are sure, really sure, that all your runtime libraries settings are consistent. No third party libraries?
From your last post... you've upgraded the compiler to VS2010, and your program is still trying to load a VS2005 DLL? If that's the case then you've definitely got "old code" being linked in.
Use the depends utility on your release mode executable and go through the various fortran and C runtime library DLL's loaded by your program and identify where they are your system. Look for "stray" DLL's that may belong to a different application (or an older version of your application) that are getting picked up from a directory in the path variable ahead of the ones installed with ifort 12 and VS2010 (I think they all reside under the respective Program files directories, anything elsewhere is broken). You can check DLL properties from within depends and inspect the compiler version that originally supplied the DLL there.
From your last post... you've upgraded the compiler to VS2010, and your program is still trying to load a VS2005 DLL? If that's the case then you've definitely got "old code" being linked in.
Use the depends utility on your release mode executable and go through the various fortran and C runtime library DLL's loaded by your program and identify where they are your system. Look for "stray" DLL's that may belong to a different application (or an older version of your application) that are getting picked up from a directory in the path variable ahead of the ones installed with ifort 12 and VS2010 (I think they all reside under the respective Program files directories, anything elsewhere is broken). You can check DLL properties from within depends and inspect the compiler version that originally supplied the DLL there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am assuming (never a good thing) that by upgrading to VS2010, the environment would automatically set up its linking to link with the new libraries, but I will check this. I did, however, fix the problem with the release version...an extra '/dll' had been inserted into the command lines for compilation, making for some strange behavior. When I corrected that the release version no longer gives me the MSVCR90.dll not found error and seems to work correctly. I still cannot sucessfully link in debug mode however. I will check the dependencies of the component DLLs, but I don't think it will tell me why the executable won't link.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The depends thing was aimed at your release problem, where you had a linked executable. The names of the C runtime DLLs are different for VS2010, but the names of the Fortran runtime DLLs are the same for the various ifort versions, so after an upgrade it is possible for oddities to occur.
Is the debug build failing still failing due LNK2005 errors? If so.. check runtime library settings, particularly for any static libraries that go into the failing link step. Check them twice.
Consider posting the build log for the project with the failing link step.
Is the debug build failing still failing due LNK2005 errors? If so.. check runtime library settings, particularly for any static libraries that go into the failing link step. Check them twice.
Consider posting the build log for the project with the failing link step.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I changed a compiler switch, disabling default library search rules and this seems to have fixed this linker problem, but why would this crop up after i upgraded the compiler? And what are the other ramifications of this compiler switch?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The requirement for that switch can be a symptom of having an object file or library in the final link step that has been compiled referencing old fortran or C runtime libraries or with inconsistent runtime library settings. I don't know what the ramifications are.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you so much for your input. It is definitly possible that I've got some old libraries (in fact I know I do), but I don't think I have an option not to use them. I'll do more digging to see what I can find out. Does anyone know, is this somthing the new compiler (Composer XE) cares about that the previous version (IF 11) didn't? That would explain why these error showed up after I upgraded.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This article on upward compability with the Fortran Compiler explains why we are not compatible with older libraries and gives some actual examples (but none for 12.1) on inconsistencies.
------
Wendy
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page