0

I have a old Visual C++ project that uses a FORTRAN static library for object creation. The current issue I have is that the project was originally made with the Compaq Visual Fortran compiler which uses the DFOR library. However, I get the error:

Error 105 error LNK1104: cannot open file 'dfor.lib'

The issue is that there are remaining references to the lib that are need to be replaced. However, I have rebuilt the project a few times, recreating all the objects that I have source files for, and the error has not resolved. I searched all the files in my project for the string dfor.lib, and these were the only resulting files.

Image of files containing string 'dfor.lib'

In the Project Linker Properties, if I remove the line /defaultlib:"dfor.lib" in the command line, I get the errors below:

Error   6   error LNK2001: unresolved external symbol "public: class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > > __thiscall petMove::toString(void)" (?toString@petMove@@QAE?AV?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@XZ) C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   23  error LNK2019: unresolved external symbol "protected: __thiscall CZoomView::CZoomView(void)" (??0CZoomView@@IAE@XZ) referenced in function "protected: __thiscall CPowerNetworkCaptureView::CPowerNetworkCaptureView(void)" (??0CPowerNetworkCaptureView@@IAE@XZ)   C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   24  error LNK2019: unresolved external symbol "protected: virtual __thiscall CZoomView::~CZoomView(void)" (??1CZoomView@@MAE@XZ) referenced in function "public: virtual __thiscall CPowerNetworkCaptureView::~CPowerNetworkCaptureView(void)" (??1CPowerNetworkCaptureView@@UAE@XZ)    C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   7   error LNK2019: unresolved external symbol "public: __thiscall CDialogCurrentPhasor::CDialogCurrentPhasor(class CWnd *)" (??0CDialogCurrentPhasor@@QAE@PAVCWnd@@@Z) referenced in function "public: void __thiscall CCurrentPhasor::SEDialogHandler(void)" (?SEDialogHandler@CCurrentPhasor@@QAEXXZ) C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureDoc.obj Power Network Capture
Error   5   error LNK2019: unresolved external symbol "public: class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > > __thiscall petMove::toString(void)" (?toString@petMove@@QAE?AV?$CStringT@DV?$StrTraitMFC@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@XZ) referenced in function "public: int __thiscall CPowerNetworkCaptureDoc::PushMove(class petMove *)" (?PushMove@CPowerNetworkCaptureDoc@@QAEHPAVpetMove@@@Z)  C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureDoc.obj Power Network Capture
Error   22  error LNK2019: unresolved external symbol "public: unsigned int __thiscall petMove::getPartType(void)" (?getPartType@petMove@@QAEIXZ) referenced in function "protected: void __thiscall CPowerNetworkCaptureView::OnChar(unsigned int,unsigned int,unsigned int)" (?OnChar@CPowerNetworkCaptureView@@IAEXIII@Z)    C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureView.obj    Power Network Capture
Error   14  error LNK2019: unresolved external symbol "public: virtual __thiscall CDialogRunAnalysisFromFilePF::~CDialogRunAnalysisFromFilePF(void)" (??1CDialogRunAnalysisFromFilePF@@UAE@XZ) referenced in function "protected: void __thiscall CPowerNetworkCaptureDoc::OnAnalysisRunFromFilePF(void)" (?OnAnalysisRunFromFilePF@CPowerNetworkCaptureDoc@@IAEXXZ)    C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\Power Network CaptureDoc.obj Power Network Capture
Error   3   error LNK2019: unresolved external symbol _HtmlHelpW@16 referenced in function "protected: void __thiscall CMainFrame::OnHtmlHelp(void)" (?OnHtmlHelp@CMainFrame@@IAEXXZ)   C:\Users\Gavin\Desktop\College stuff\1st year (Fresher)\Pet_Gavin\pet_neda\MainFrm.obj  Power Network Capture

There are a few more but they are very similar to these ones.

Are these errors ones that would be easier to resolve or do they indicate that the command of /defaultlib:"dfor.lib" is needed?

Gavin Chandler
  • 37
  • 8
  • Does __USE DFOR__ appear anywhere in your code? This tells the code to use dfor.lib – cup May 27 '18 at 15:35
  • @cup I do not see any references to DFOR in any of the code, let alone USE DFOR. The only files it did appear in were the project and log files as seen in the image. – Gavin Chandler May 27 '18 at 15:54
  • Could you post what unresolved external symbols you get if you remove /defaultlib:dfor.lib? If it is a whole bunch of routines that end with QQ,try either dflib.lib or ifqwin.lib – cup May 27 '18 at 19:59
  • @cup Thanks for the reply and help, I just added most of the errors to my original post. I will try the two routines you said and report any progress in the meantime. – Gavin Chandler May 27 '18 at 20:29
  • If I use ifqwin.lib, I get more errors with unresolved externals, and if I try dflib.lib, I get an error that it cannot open – Gavin Chandler May 27 '18 at 20:37
  • Those look like a missing MFC C++ library in the link line. Look for CZoomView, CDialogCurrentPhasor and CDialogRunAnalysisFromFilePF. It is not an ifqwin or dflib problem. – cup May 28 '18 at 05:20
  • It seems I have all a C++ and header file for each of those and they all contain references to the C*** dialog but I have no files named CZoomView or the others. – Gavin Chandler May 29 '18 at 00:56

1 Answers1

1

The mention of CMainFrame in your last error suggests you have an MFC based project here. However the CMainFrame class is normally part of the MFC project, defined in the files MainFrm.h and MainFrm.cpp. If your project was originally generated by Visual Studio then your project's ReadMe.txt file should confirm that.

It seems somewhat suspicious that CMainFrame::OnHtmlHelp would have an unresolved reference - but I'm definitely not an MFC expert!

It appears support for HTML Help in MFC applications ended with Visual Studio 2010. The Advanced features page of the MFC Application Wizard includes a checkbox for Context-sensitive help (HTML). The documentation for that checkbox points to more information.

In Visual Studio 2010 Documentation the Advanced features page points to this page. However in the Visual Studio 2012 documentation the Advanced features page point to this page which says …

Important
HTML Help is not supported in this version of MFC.

The Visual Studio 2013 documentation points to a similar page

The What's New for Visual C++ in Visual Studio 2012 and Breaking Changes in Visual C++ 2012 pages don't mention HtmlHelp being de-implemented nor do they mention a replacement or workaround.

There's this unanswered SO question: htmlhelp.lib for Visual Studio 2012 MFC app?.

I don't recognise CZoomView, CDialogCurrentPhasor or CDialogRunAnalysisFromFilePF (which doesn't necessarily mean very much). They don't appear in Visual Studio 2013's MFC documentation which suggests either they are defined in your project or are part of some third-party package.

Are you sure your build is compiling all of the .cpp files it should compile? Have you tried rebuilding the entire solution?

If those are classes defined by your project, it is possible they're impacted by the Htmlhelp issue.

You should probably start by trying to resolve the LNK2001 CStringT error since it is first. The other errors might be downstream effects of that error (if you are lucky).

… long misleading (and wrong) section deleted …

Taking a second look at that error I realise I was sending you off in completely the wrong direction by focusing on CStringT. The pertinent part of the error text is...

error LNK2001: unresolved external symbol 
  "public: class ATL::CStringT<char,class StrTraitMFC<char,class ATL::ChTraitsCRT<char> > >
  __thiscall petMove::toString(void)"

The unresolved symbol is the function petMove::toString(void) the ATL::CStringT< … > part is the return type of the function. The sixth error down is for the related function petMove::getPartType(void) which returns an unsigned int.

Assuming petMove is a class (or struct) defined in your project, perhaps examining the implementation of that class will tell you something about the link errors.

For example the implementations of petMove::ToString and petMove::getPartType might be missing; or commented out; or elded by an incorrect #ifdef.

The other four missing symbols are all constructors or destructors

CZoomView::CZoomView(void)
CZoomView::~CZoomView(void) 

CDialogCurrentPhasor::CDialogCurrentPhasor(class CWnd *)

CDialogRunAnalysisFromFilePF::~CDialogRunAnalysisFromFilePF(void)

Is it possible your project is missing some implementation files for CZoomView, CDialogCurrentPhasor and CDialogRunAnalysisFromFilePF? Alternatively you may have a header file that defines constructors and/or destructors that your implementation .cpp file doesn't declare.

For example this header defines two constructors ...

// CZoomView.h 
class CZoomView
{
public:
   CZoomView();
   CZoomView(int);
   // ...
};

… but this implementation file only declares one of them …

// CZoomView.cpp

// Simulate missing ctor
//CZoomView::CZoomView()
//{
//}

CZoomView::CZoomView(int)
{
   // ...
}

That combination will compile successfully but will give a linker error LNK2019

Frank Boyne
  • 4,400
  • 23
  • 30
  • Thanks so much for the help. I am new to all of this so it may take me a while to figure out how to do this and test all these solutions, but I will get back to you on the results. Also one last question, should I just delete the /defaultlib:dfor.lib? Also I have tried rebuilding the entire solution multiple times and all the fortran compile correctly but it fails and quites after trying to generate the code and loading the object files. – Gavin Chandler May 29 '18 at 22:17
  • Also it seems I am missing both of those header files for CStringT. – Gavin Chandler May 29 '18 at 22:30
  • Tentatively, yes you should delete the `/defaultlib:dfor.lib` subject to the caveat that as we resolve your problems we might uncover new problems that would force us to add it back in. – Frank Boyne May 30 '18 at 06:45
  • When you say you are "missing both those header files" do you mean you can't find them on your system or you can't find a `#include` that mentions them? Something must be defining `CStringT` or the `.cpp` files containing `CStringT` wouldn't compile. One way to explore this would be to right-click on a mention of `CStringT` in one of your `.cpp` files and then click on "Go To Definition" in the resulting context menu. That will open up the header file Visual Studio thinks is used to define that type. Right-click the file's name tab and then click on Open File Folder to go to its location. – Frank Boyne May 30 '18 at 06:47
  • I searched with agent ransack and found that there are no files named `CStringT` and the only mentions of it are in the object files, precompiled header file, and the project file. I found the same for the string `atlstr`. However, there are many mentions to `CString` in the source code, but none to `CString.h`, and there are also mentions to `CStack.h`. However, I did find `CStringT.h` in **C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\atlmfc\include\**. – Gavin Chandler May 31 '18 at 02:43
  • Also while reviewing some of my properties, I noticed that for my fortran static library `Configuration Properties< Fortran < External Procedures < Calling Convention` was set to **CVF (/iface:cvf)**. I tried setting this to **default** but I saw no immediate results. – Gavin Chandler May 31 '18 at 17:41
  • Re May 31 at 2:43: Sorry I should have been less ambiguous. CStringT is a [standard type provided by Microsoft](https://learn.microsoft.com/en-us/cpp/atl-mfc-shared/reference/cstringt-class). Your program should only have to #include` or `#include` some other file which in turn includes `CStringT.h`. – Frank Boyne Jun 04 '18 at 06:53
  • Re May 31 at 17:41 : You should probably change the Calling Convention back to CVF (if you haven't already done so). Calling Conventions are likely to affect run-time behaviour, not compile-time behaviour. – Frank Boyne Jun 04 '18 at 06:56
  • I've taken another stab at the last part of the answer. I got rid of the misleading (and erroneous) `CStringT` discussion and replaced it with something more focused - and hopefully more useful. – Frank Boyne Jun 04 '18 at 07:57
  • Hello Frank, thanks for the help, it seems the project was not included the cpp file ChangeInput.cpp that details the `petMove::ToString` and other functions. I am currently adding it and fixing an error with the code but it seems to have fixed at least that problem. – Gavin Chandler Jun 04 '18 at 17:04
  • The only remaining errors are the `"public: virtual __thiscall"` and `"public:__thiscall"` errors. – Gavin Chandler Jun 04 '18 at 17:26