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.
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'm really confused, i'm stuck with this problem, i hope you can help me :
I use : Windows 8.1, Visual Studio Express 2013 and SOCI 3.2.2
I have compiled both libsoci_mysql and libsoci_core and linked them into my project, but when i launch the compilation this error appear :
Error 1 error LNK2001: external symbol unresolved "struct soci::mysql_backend_factory const soci::mysql" (?mysql#soci##3Umysql_backend_factory#1#B) dbConnection.obj Server
I'm a little bit lost with Window, but i'm praticly sure libsoci_mysql.lib is found and (i have open the .lib with GNU emacs) contains the symbols.
Looks like it's a known problem with MSVC. The proposed workaround is to replace soci::mysql usage with *soci::factory_mysql().
In case someone else stumbles upon this I ran into a similar problem where odbc_option_driver_complete was undefined.
The issue was that this is defined in the header as an external and implemented in DLL. By default when building the DLL the code sets up a #define to eventually set __declspec(dllexport) for the external.
However, when you include the header in your code it does NOT by default set __declspec(dllimport) for the external! To trigger this you must #define SOCI_DLL in YOUR project to set this up.
Ideally your should set this in Project Properties -> C/C++ -> Preprocessor -> Preprocesor Definitions
I've build an incredibly simple container (barely more than a struct) as a simple test of templates and libraries in c++. It holds an arbitrary type of data and keeps track of it's highest valued member and whether the data has changed since it was last accessed, and is contained in tiny .dll generated by the newest msvc compiler. All I want to do is link this library to another project in Qt Creator, which I've configured to use msvc as it's compiler ( I need to use Qt to interact with .ui files efficiently). I get an unresolved external symbol for each function in the object that is called, e.g. :
LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall collectionContainer<int>::collectionContainer<int>(int *,short,long)" (__imp_??0?$collectionContainer#H##QAE#PAHFJ#Z) referenced in function _main
I'm not sure what to do here, as I was under the impression that that is the exact symbols I should expect to see when exporting a library.
The functions all have CONTAINER_API defined in the usual way that visual studio conditionally imports/exports functions. I'm sure I've just misinterpreted something, but I'm running out of ideas.
I wonder if this error has nothing to do with DLLs and it's just a case of not putting the template implementation in a header file. See here
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'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.