Linking to MFC and CRT dynamically and statically in one image

If you link your MFC application that consumes MFC static lib, often you may encounter a situation when your app dynamically links to MFC and your library statically links to MFC. When you build this application and you are going to get similar to ones listed below:

1>msvcrtd.lib(ti_inst.obj) : error LNK2005: “private: __thiscall type_info::type_info(class type_info const &)” (??0type_info@@AAE@ABV0@@Z) already defined in libcmtd.lib(typinfo.obj)

1>msvcrtd.lib(ti_inst.obj) : error LNK2005: “private: class type_info & __thiscall type_info::operator=(class type_info const &)” (??4type_info@@AAEAAV0@ABV0@@Z) already defined in libcmtd.lib(typinfo.obj)

1>LINK : warning LNK4098: defaultlib ‘mfc80ud.lib’ conflicts with use of other libs; use /NODEFAULTLIB:library

1>LINK : warning LNK4098: defaultlib ‘mfcs80ud.lib’ conflicts with use of other libs; use /NODEFAULTLIB:library

1>LINK : warning LNK4098: defaultlib ‘msvcrtd.lib’ conflicts with use of other libs; use /NODEFAULTLIB:library

To resolve these errors, you need to link to MFC in one way across your solution. It can be either statically or dynamically and you need to decide which one you need. Then check Project Properties for all projects in your solution. Look for /D_AFXDLL. Look for how /MD[d] vs. /MT[d]. All your projects have to have one setting here – either all of them define _AFXDLL and do /MDd, or none defines _AFXDLL and all of them statically linked to MFC.

Note that I do not actively post on MFC framework anymore because it was not the main area of my focus. Last years I was posting on web
, program
and project
. Below are some other posts on MFC:

  1. Windows Forms and MFC Integration using CWinFormDialog
  2. Complete
    Example of MFC and Windows Forms Integration
  3. Integrating
    Windows Vista Aero Wizards into existing MFC Applications
  4. Resolving
    common error around resolving private member during porting MFC

If you have questions and need more help in integrating Windows Forms in your
MFC applications, please ask questions on Visual C++
MFC forum

Comments (7)

  1. bruteforce says:

    That’s good to know, thanks.

    I had a similar problem so by googling around the linker errors I eventually got to your page.

    I had a project that was linking dynamically to MFC and the CRT and wanted to switch both to static linking. However link failed with a message that operator new and operator delete were found in both nafxcw.lib and libcmt.lib.

    I turned linker verbose output ON, but go nothing useful from that.

    After struggling for a little while I started a new test MFC project (dialog based) with static MFC/CRT linking and started comparing the compiler and linker command lines.

    With a gasp of surprise I realised that my project was NOT using precompiled headers. Sure as hell stdafx.h/cpp were there but a previous dev had turned it off for some reason.

    As soon as the precompiled header came to life, I linked successfully.

    The problem will not reproduce itself if you just make the test project above compile without precompiled headers (I didn’t spend too much time trying…). My project was originally a VC71 project which was at some point converted to VC80.

    I know there must be some technical explanation for this behaviour (please enlighten us) but it is definitely confusing. Couldn’t VS2005 identify this situation and give us some warning or something?

    Warm Regards,

    Dimitris Staikos

  2. NikolaD says:

    I doubt that pre-compiled headers support may have anything to do with this error. I would look for different compilation switches on files in project. Perhaps the same dev have set some compiler options of each file.

  3. DanQuixote says:

    Pre-compiled headers definitely have something to do with this design bug.

    To reproduce it, you have to turn off pre-compiled headers (the world is just simply bigger than the stdafx.h hack!), use static libraries, and then link in an extra library such as opengl32.lib.

    This triggers the problem in both VC6 and VC8.

    The work-around for VC8 (Visual Studio 2005) is:

    1. Project -> Properties

    2. Set Configuration = Debug

    3. Select Configuration Properties -> Linker -> Input

    4. Ignore Specific Library = uafxcwd.lib

    5. Additional Dependencies = uafxcwd.lib (plus any add-on libraries such as version.lib or boost___.lib)

    6. Set Configuration = Release

    7. Select Configuration Properties -> Linker -> Input

    8. Ignore Specific Library = uafxcw.lib

    9. Additional Dependencies = uafxcw.lib (plus any add-on libraries such as version.lib or boost___.lib)

    Hope this is helpful to many!


  4. J. White says:

    You are probably aware that this problem also arises when trying to link .C files compiled as ‘C’ with an MFC app.  I had a similar problem trying to link nafxcwd.lib and Libcmtd.lib.  I previously fixed this for a VC6 project.  (Basically, you are forcing the order in which the libraries are used by removing them from the list the linker thinks it needs and then manually add them back in.)

    Having ported the project to VS2003, I knew what needed to be fixed but couldn’t remember the steps.

    Thanks for the instructions – it saves me having to experiment.

  5. jyner_ix says:

    <a href= >cca catalog shopping</a> <a href= >centruy 21 professional realty in hudson florida</a> <a href= >automax dealership killeen</a> <a href= >blue bells drawings and sketches</a> <a href= >bridgewaters seaport</a>