I'm updating some legacy apps to Visual Studio 10 and am in linker hell. All of these DLLs derive classes from CWinApp and use AfxGetApp() to get access to the object. When I link the DLLs I get unresolved externals that look like global static objects that would get pulled in by a normal app's main():
Shell.lib(SHELL.obj) : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const CException::classCException" (?classCException#CException##2UCRuntimeClass##B)
Shell.lib(SHELL.obj) : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const CFrameWnd::classCFrameWnd" (?classCFrameWnd#CFrameWnd##2UCRuntimeClass##B)
Shell.lib(SHELL.obj) : error LNK2001: unresolved external symbol "public: static class CRect const CFrameWnd::rectDefault" (?rectDefault#CFrameWnd##2VCRect##B)
My current combination of ignore default libraries and additional libraries (the method you can easily google to find the answer to linker hell) is: msvcprtd.lib,mfc100d.lib,mfcs100d.lib,libcmtd.lib
When I add nafxcwd.lib (the mfc library), these three external symbols resolve but I end up with a bunch of other duplicate symbols (requiring the use of /FORCE:MULTIPLE) and in end ___argc and ___argv become unresolved.
So the basic question is: Can you link a DLL containing a CWinApp in VS10? How do you setup the linker to do it?
Can you link a DLL containing a CWinApp in VS10?
When I create a new project in Visual Studio 10 and use the MFC DLL template, I found the template code itself includes a class derived from CWinApp. Of course the template compiles and links fine, so the answer to this question is a most definite yes.
I searched for definitions to those objects that your linker is complaining about and I found them in afx.h and afxwin.h, inside Visual Studio's include directory, packaged with the rest of the ATL and MFC code that is included with Visual Studio when you install it.
Are you using the express edition by chance? One of the few differences between the express edition and the pro edition of Visual Studio 2010 is that ATL and MFC applications won't compile in the express edition. You have to use the pro edition.
Related
For a research project, I'm writing a C++ add-on to a scientific computing language. Unfortunately the library that allows users to do this is not kept very well up-to-date.
I started the project in XCode, where it built fine. Later I had to move to a PC, so I migrated the code to Visual Studio 2015. Since doing this, I haven't been able to build due to the following errors:
LNK2001 : unresolved external symbol _sprintf
LNK2019 : unresolved external symbol _sscanf referenced in function _GetDDouble
LNK2019 : unresolved external symbol _sprintf referenced in function _CheckRunningInMainThread
An attempted fix was to add the header #define _CRT_SECURE_NO_WARNINGS. However, this a) fixed no errors and b) added the warning C4005 : '_CRT_SECURE_NO_WARNINGS': macro redefinition. I assume the library already defined this macro, anticipating this problem. Regardless, it didn't solve the problem.
How should I proceed?
Add the following library to the linker input files:
legacy_stdio_definitions.lib
VS 2015 now uses inline definitions that call internal functions for many of the stdio.h functions. If an object file (or library member) depends on one of those functions, then the legacy_stdio_definitions.lib provides an externally linkable version of the function that can be linked to.
Your other option is to recompile the unit that depends on those functions with VS 2015 (this is probably the preferred option).
I got this error compiling cycling max plugins against version 5 max sdk (pure c api). The legacy library fix didn't work for me (it should have, and if anyone had any idea why it mightn't I'd be curious), but I defined _NO_CRT_STDIO_INLINE before stdio was loaded and that did do the trick.
I recently encountered this and was able to add User32.lib to Linker > Input > Additional Dependencies.
You could also include #pragma comment (lib, "User32.lib") in your code.
I created a default ATL project with MSVC 2010 with a simple default ATL dialog. Then I added the second project into solution, named MyControls, where I created ATL DHTML Control with a help of Wizard. Then I placed ATL DHTML Control to ATL dialog.
Now I would like to call some methods of that ATL DHTML Control in ATL dialog's OnInitDialog function. In order to be able to make a call like:
CComPtr<IDHTMLControl> ptr;
HRESULT hr = GetDlgControl(IDC_ACTIVEX_CONTROL_DHTML
, IID_IDHTMLControl, (void**)&ptr);
I am including the file DHTMLControl.h from MyControls project. However, I get the following errors:
Error 1 error LNK2001: unresolved external symbol _IID_IDHTMLControl
Error 2 error LNK2001: unresolved external symbol _LIBID_MyControlsLib
Error 3 error LNK2001: unresolved external symbol _CLSID_DHTMLControl
Error 4 error LNK2001: unresolved external symbol _IID_IDHTMLControlUI
Note: It appears that I am linking MyControls.lib incorrectly, however, I added MyControls.lib to Linker->Input->Additonal Dependencies & specified ../$(Configuration) in the Linker->General->Additional Library Directories.
Anyone have an idea?
Thanks!
The problem is related to how you link one project with the other. There is something missing here and since you don't show the code, it's a pure guess only.
On control project you have a type library which, when being built, also generates files MyControls_i.h, MyControls_i.c, MyControls_p.c. I suppose that on the application project you included _i.h file which declared symbols as externals, and you did not include the _i.c file with symbols actually defined.
Link errors like this sometimes occur when compiling C++ using Microsoft Visual C++ 6.0:
error LNK2001: unresolved external symbol __imp__close
error LNK2001: unresolved external symbol __imp__read
error LNK2001: unresolved external symbol __imp__lseek
error LNK2001: unresolved external symbol __imp__open
My fix, which I found after searching fruitlessly using Google for a long time, is this:
Do NOT disable language extensions. In the Project Settings dialog, in the C/C++ tab, make sure that the 'Disable language extensions' checkbox is not checked.
The functions close, read, lseek, open, etc., are not standard parts of the C library and the declarations are skipped by conditional compilation using #if !__STDC__ in <io.h>. This happens if you disable language extensions.
The answer is that the __imp prefix refers to function stubs in the OBJ library for the DLL version of the CRT. This means your linker options are incompatible with your compiler options (linker set to static CRT or no CRT and compiler set to dynamic CRT).
In your case rather than the CRT itself it is another library, but the same idea.
I created my own ODBC wrapper class which handles SQL from C++ Win32 application.
I have copied and Added (as existing) this class to my MFC application.
Now I have terrible linking problems with unresolved external symbols (which were NOT present in the Win32 perfectly working app), such as this: "
Error 56
error LNK2019: unresolved external symbol _SQLSetStmtAttr#16 referenced in function
"public: int __thiscall Cosql::ODBCconnect(char *)" (?ODBCconnect#Cosql##QAEHPAD#Z)
C:\Documents and Settings.........\Cosql.obj ApplicationName
"
How can I PROPERLY include "sqlext.h" (and "sql.h") from
C:\Program Files\Microsoft SDKs\Windows\v7.0A in my MFC application or MORE importantly: How to resolve those external symbols?
Am I the only one trying to ODBC-connect from a MFC app and having this trouble ??? :O
I Just know that "SQLSetStmtAttr" function is there defined only for ODBCVER 3.0 and higher. Well ! But HOW do I set ODBCVER in my MFC app. ??? I have no idea.
EDIT: I figured out that ODBCVER is defined: 0x0380 (so it is ver. 3.8),
all functions are defined correctly by those includes: sql.h and sqlext.h ,
EDIT II: Linking ERROR persists when I convert all those methods (object) into pure functions using some global variables!
Thanx in advance.
Solved.
Solution: I created a DLL from my ODBC class and then used it in my project.
Now it is compiled independently so it does not restrict each other's INCOMPATIBLE environment and compiler settings anymore!
I have successfully upgraded an MFC application which was compiled with an old version of Developer Studio to Visual Studio 2008. A very small number of changes were needed because of some breaking changes in MFC. Now that everything works, I'd like to take the next step and compile the solution with /clr.
To do so, I have found useful information on the MSDN web site:
How to: Migrate to /clr
How to: Compile MFC and ATL Code with /clr
Here are the steps I have taken:
Set the Runtime Library to Multi-threaded Debug DLL (/MDd).
Set the Use of MFC to Use MFC in a Shared DLL.
However, doing so prevents me from linking the project:
The reference to afxData can no longer be resolved; somehow, afxData is only visible when linking statically against MFC. In my code, I have the following declaration:
extern AFX_DATA AUX_DATA afxData;
which works fine with the statically linked MFC version.
The references to _afxThreadState and _afxWinState cannot be resolved either.
Here are the full error messages :
error LNK2001: unresolved external symbol "struct AUX_DATA afxData" (?afxData##3UAUX_DATA##A)
error LNK2001: unresolved external symbol "class CThreadLocal<class _AFX_THREAD_STATE> _afxThreadState" (?_afxThreadState##3V?$CThreadLocal#V_AFX_THREAD_STATE####A)
error LNK2001: unresolved external symbol "class CProcessLocal<class _AFX_WIN_STATE> _afxWinState" (?_afxWinState##3V?$CProcessLocal#V_AFX_WIN_STATE####A)
in case this might be related to the name mangling...
So, what can I do in order to dynamically link against MFC, but still reference afxData, _afxThreadState and _afxWinState?
When using MFC in a shared DLL, AUX_DATA must be dllimported.
extern __declspec(dllimport) AUX_DATA afxData
For thread state, rather than using template classes, use one of these
AFX_MODULE_THREAD_STATE* pState = _AFX_CMDTARGET_GETSTATE()->m_thread;
AFX_THREAD_STATE* pState = AfxGetThreadState();
Depending on the state information you require. For example, see here for some members that were moved to module state to fix a bug. Note that AfxGetModuleThreadState exists but is undocumented and could be changed in a future version.
Win state does not ring a bell, how is it used? There is probably a new way to accomplish it.