MFC error LNK2001 problem

Dear experts,

After changing the DLL project to release mode, I have got the following errors:

mfcs42d.lib(dllmodul.obj) : error LNK2001: unresolved external symbol "void __cdecl AfxTrace(char const *,...)" (?AfxTrace@@YAXPBDZZ)
mfcs42d.lib(dllmodul.obj) : error LNK2001: unresolved external symbol "public: static void * __stdcall CObject::operator new(unsigned int,char const *,int)" (??2CObject@@SGPAXIPBDH@Z)
mfcs42d.lib(dllmodul.obj) : error LNK2001: unresolved external symbol "int __stdcall AfxAssertFailedLine(char const *,int)" (?AfxAssertFailedLine@@YGHPBDH@Z)
mfcs42d.lib(dllmodul.obj) : error LNK2001: unresolved external symbol "class CWinApp * __stdcall AfxGetApp(void)" (?AfxGetApp@@YGPAVCWinApp@@XZ)
Release/abc.dll : fatal error LNK1120: 4 unresolved externals

How can I tackle this error? Thanks a lot.
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

jhanceConnect With a Mentor Commented:
You are still telling the linker to link with:


which is the DEBUG library but the rest of your program is non-debug.

In VC++, open the project and choose Project>Settings.

Select "Settings For:" to be the Win32 Release for your project.

Then click the C++ tab and choose Code Generation from the dropdown list.

Make sure the Use runtime library says Multithreaded or SingleThreaded (as opposed to Debug Multi, etc.)

Save the project and recompile.
pigpigAuthor Commented:
I think I have got the right setting:
Multithread DLL (as it is a DLL project)

I tried to ignore the mfcs42d.lib in the setting and I have got another error.

What is it that you're linking?  Some OBJ files, obviously.  Do you have any LIB files that you've built yourself, or you get from a 3rd party?  Where do all of the OBJ files come from?

It's apparent that at least one file was built debug, and is referencing the MFC debug libraries.

..B ekiM
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

pigpigAuthor Commented:
In the project setting, in the link input,
I just put "mfcs42d.lib MSVCRTD.lib" in the Object/lbirary modules,
and "mfcs42d.lib MSVCRTD.lib" in the ignore libraries.

If I don't do this, I will have this error:
mfcs42.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRT.lib(dllmain.obj)
mfcs42.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in MSVCRT.lib(dllmain.obj); second definition ignored
   Creating library Release/xxx.lib and object Release/xxx.exp
xxx.exp : warning LNK4070: /OUT:xxx.dll directive in .EXP differs from output filename "Release/xxx.dll"; ignoring directive
Release/xxx.dll : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.

xxx.dll - 2 error(s), 2 warning(s)
Since you're building for release, you shouldn't be fooling with the debug libraries.  That is, you should be fooling with mfcs42.lib and msvcrt.lib, not mfcs42d.lib and msvcrtd.lib.

..B ekiM
pigpigAuthor Commented:
so... how can I tell MFC not to use these libraries without getting errors?

MFC emits default library records in any OBJ file you build. There are several #pragmas in the MFC headers which do this. The idea is that you shouldn't have to explicitly reference _any_ MFC or system libraries when you build.

The #pragmas are gated by #ifdef's that decide which library variant is used. If _DEBUG is defined, the debug builds are referenced--if _DEBUG isn't defined, the release libraries are referenced. Different libraries are referenced in different places, but the bulk of the action is right near the beginning of AFX.H.

If you're positive that you're not explicitly referencing the debug libraries in your release builds, then the most likely explanation is that you're including an OBJ or LIB file that was built for debug in your release builds. The default library record is glued into the OBJ or LIB files, and the linker will dutifuly follow the recommendation of the record when linking.

Maybe you have a broken build process. Maybe you've got some bad OBJ files stuck in a LIB you're referencing. Maybe you're purposefully mixing debug- and release-built objects and weren't aware that they're incompatible.

You can use the /VERBOSE option of the linker to figure out which module is causing the reference. It'll cause the linker to spew a lot of output, but that output will contain the answer.

..B ekiM
pigpigAuthor Commented:
Thanks B ekiM very much!

I can solve like this:
In the project setting, in the link input,
I put "mfcs42.lib MSVCRT.lib"
in the Object/lbirary modules,
and "mfcs42d.lib MSVCRTD.lib"
in the ignore libraries.
That's a bad solution.  Since you have code which is expecting the debug build of MFC, it was compiled with the _DEBUG flag. The code is expecting debug signals, debug memory patterns, and the size of all internal structures to match that of a debug build.

By forcing the libraries the way you are, you're mixing-up those patterns. You'll have lots of odd behaviour caused by the resulting memory overruns and overwrites, and will probably end up with additional unresolved symbols.

..B ekiM
All Courses

From novice to tech pro — start learning today.