Help needed with LNK error

[dboggs]

I'm building an application (Quickwin) on computer A and everything goes OK.

I then copy all the source files and VS files onto computer B. The source files compile OK, but they will not link. I get the error/message "fatal error LNK1104: cannot open file 'dfor.lib'. I do not know what this library file is, it is not mine, and I'm not explicitly calling anything in it.

As far as I can tell, the environment on computer B is identical to A. Both are running 2011.8.278. The installation on both computers was from the same setup file w_fcompxe_2011.8.278. I have not (knowingly) modified any of the default library searches, etc.

I don't even know what to look for. Help!

btw, why is it so hard to search documentation for error messages? Should I be able to find something about LNK1104 on my own? I tried...

[Steven_L_Intel1]

Well, even if you had found documentation for LNK1104 (it's a Microsoft linker error and a Google search turns up the MS documentation as the top hit), it wouldn't tell you anything more than the message text.

The key here is the name of the library it is looking for - dfor.lib. This is the Compaq (or Digital) Visual Fortran run-time library. What this tells me is either 1) You did not recompile all the sources and are including an object or library file built with CVF), or 2) you have a project setting explicitly naming dfor.lib (perhaps in the linker properties).

If this is not enough of a clue for you to find the culprit, I suggest downloading File Locator Lite (this is an alias for Agent Ransack), one of the best free file search utilities I know of. Install this on computer B and use it to search your project for the string dfor.lib If you are linking to libraries in other directories, search those too.

[mecej4]

Here is something to try before you expend effort on obtaining a copy of the missing library.

Use /nodefaultlib:dfor.lib as a linker option.

If the linking completes, you are done; one of your objects or libraries has references to symbols in DFOR.LIB, but those references were resolved by symbols in the Intel runtime libraries.

[Steven_L_Intel1]

Using /nodefaultlib here is actually a bit risky. The reason is that most of the routines in dfor.lib have the same names in libifcore.lib (the Intel Fortran library) but most are not call-compatible. So you might get the link to succeed but the program fails in bizarre ways.

Also, don't even think of trying to get a copy of dfor.lib, as that will just introduce more link errors. The real solution is to identify which object or library is being linked in that still asks for dfor.lib and recompile it.

Another option that may help is Linker > General > Show Progress > Show some progress messages. This will show you the library directives as they are seen by the linker and, often, you can identify the object that made the reference.

[dboggs]

Thanks for your help, Steve. You led md right to the problem.

For the record, my program calls routines from our own library, ourlib.lib. The library was originally created on computer B usingCVF. Two years ago, when I first migrated to IV, working on computer A I recompiled the library using IVF. Then I forgot about it. Returning now to computer B after a long absence, I hadn't rembered that our library there was compiled with CVF.

I was able tosolve the problem by getting ourlib.lib from computer A and copying it onto computer B.

I hadn't even thought about the fact that this would be necessary--I simply assumed that if two files are named ourlib.lib, andall of the source files are equivalent, then the lib files are also equivalent! I should have known better but now I do.