0

Working in Visual Studio 2013 Professional and I have been trying to debug old code from a VC++ 6 Project. When running the scripts, the error :

Error LNK1104: cannot open file 'DFOR.lib' Visual Studio

Come up. I have tried looking into the issue and it seems that the directory needs to be added in the the project properties, however, I have had trouble finding the directory in my computer. It also does not seem to be on my Companies computer I have been using but I have had trouble finding how to obtain it otherwise.

If you could help me find the DF98 directory (which is what others seems to have used) or help me otherwise, I would appreciate it greatly.

BattleTested_закалённый в бою
  • 4,037
  • 5
  • 26
  • 47
Gavin Chandler
  • 37
  • 8

1 Answers1

2

A short file name isn't much to go on but a quick search suggests that DFOR.LIB may have been part of Compaq Visual Fortran in the distant past.

I'm not familiar with that product but it seems to have been taken over by Intel at some point. You could try asking your question in the Intel forum for Intel® Visual Fortran Compiler for Windows* or read some of the relevant posts there already.

On a more general note the documentation for LNK1104 offers some discussion of possible causes and solutions to this error.

At this point you should not assume you need to find DFOR.LIB, you need to figure out why the linker is trying to open it.

Unnecessary LIB File

For example, an unnecessary #pragma comment (lib...) statement or erroneous linker command in your build might cause the linker to try and read DFOR.LIB even if it isn't needed to complete linking your code file.

In that case, the solution would be to delete (or comment out) the unnecessary #pragma comment (lib...) statement or remove the DFOR.LIB reference from the linker command and rebuild your project.

In Visual Studio, the likely place to find an unnecessary LIB file reference is in Project Properties | Linker | Input in the "Additional Dependencies" property. When changing this property remember to do so for all configurations and all platforms (not just Debug & Win32). For a make file or other command-based build linker input files are listed one at a time in the linker command without a specific switch.

Project Properties | Linker | Input

A second place you might find an unnecessary file reference is the Linker's /DEFAULTLIB command. There is no specific Visual Studio property corresponding to this switch but it can be specified in the Command Line property.

Project Properties | Linker | Command Line

Required LIB File

On the other hand, if the linker is reading DFOR.LIB to resolve some reference then you need to figure out what part of your code is causing DFOR.LIB to be required.

In the simple case your code is directly calling a function implemented in DFOR.LIB which the linker is trying to resolve. The linker's list of unresolved references might help you figure out the function name.

In the less simple case your code might be calling a function in some other library file which in turn calls a function (or functions) in DFOR.LIB.

In both cases the linker /VERBOSE and /FORCE options may help you gather more data.

Once you know which part of your code results in the need to link to DFOR.LIB you can decide what to do about it.

  • You might rewrite the code to use a different function in some package you do have access to
  • You might find a more modern (and supported) implementation of that function - in Intel's Visual Fortran implementation for example
  • You might find a licensed copy of Compaq Visual Fortran (and hope that it still runs on modern systems)
  • You might find that Visual Fortran is a red herring and that your DFOR.LIB comes from some completely different package
Frank Boyne
  • 4,400
  • 23
  • 30
  • Thank you for the help Frank. I am not very experienced with Fortran but did realize that the issue had to do with the Compaq Visual Fortran compiler. I am currently trying to find the cases where DFOR.LIB appears and it seems it is in a link comment file and the main project file among other things. – Gavin Chandler May 16 '18 at 21:37
  • I did a search through my project files for the string DFOR.LIB and DFOR and the only references seemed to be from the project files and build logs. I do believe that the reference is unnecessary but not sure how to get rid of it. – Gavin Chandler May 27 '18 at 16:07
  • The use of the linker /VERBOSE reveals **Processed /DEFAULTLIB:dfor.lib** once the project generating the code. – Gavin Chandler May 27 '18 at 16:14
  • It sounds like you may have a rogue /DEFAULTLIB switch. See the updated answer for more info. – Frank Boyne May 27 '18 at 17:52
  • The updated answer helps a lot but I am new with Visual Studio, so I identified a **/defaultlib:"dfor.lib"** in my command line. What should I replace it with, because otherwise there are errors for the unresolved external symbols when I rebuild. – Gavin Chandler May 27 '18 at 19:29
  • We're back to that first "Do you need DFOR.LIB" question. If those unresolved external symbols should have been resolved by DFOR.LIB then you'll have to explore the *Required LIB File* section - either find a DFOR.LIB, find an alternative to DFOR.LIB or replace the function calls and other code causing those unresolved symbols. On the other hand those external references may be unrelated to DFOR.LIB in which case they're unrelated errors that need to be resolved. The names of the unresolved symbols may offer a clue one way or the other. – Frank Boyne May 27 '18 at 22:37
  • I was discussing this issue with others and they suggested that this seemed like a issue with a missing MFC C++ library in the link line rather than an issue with DFOR.LIB. They suggested I look for CZoomView, CDialogCurrentPhasor and CDialogRunAnalysisFromFilePF. If you want to check out the specific errors, I posted them in a more recent thread when I had figured the problem out more thoroughly. https://stackoverflow.com/questions/50548321/references-to-dfor-lib-from-compaq-visual-fortran – Gavin Chandler May 29 '18 at 00:42