none
Link errors when statically linked MFC application and extension library are built with /Zc:wchar_t- RRS feed

  • Question

  • We have to build an MFC application with /Zc:wchar_t- . This application depends on MFC and a custom MFC extension library (and additional old dependencies which require /Zc:wchar_t- ). Both the application and the MFC extension library are built with /Zc:wchar_t-, and when the application is linked dynamically, it works fine.

    When we use static link with the extension library ( we also link to MFC, does not matter statically or dynamically), there are multiple link errors, like if the application an library would be built with different compiler option. Does this have a known reason or we missed something in our library and application?

    I have to clarify:

    1. Indeed, all pieces are built with the same version of Visual Studio (2017 or 2019)

    2. When we use default /Zc:wchar_t, both dynamic and static link between the application and custom library works fine: the problem comes up only with /Zc:wchar_t-.

     Thanks!
    • Edited by BorisM Tuesday, December 3, 2019 1:33 PM
    Monday, December 2, 2019 11:37 PM

All replies

  • Without any indication as to what version you are building with, the link errors or what you mean by "old" then this is only a guess.

    Anyway, MFC and ATL are C++ libraries, this means that the names are mangled. The name mangling scheme isn't standard defined and so it can change and it has. I think it was between Visual C++ 6.0 and Visual Studio .NET (7) that the name mangling scheme last changed.

    What's more, Microsoft has never promised binary compatibility between major versions of the compiler/libraries. So if this extension library was built with an old version of Visual Studio and you are building code with a new version of Visual Studio but then trying to link the static library, the static library is going to be forced to use the new version of MFC to resolve the dependencies. Remember, a static library is fundamentally different from a dynamic library, a static library is just an archive of objects so dependencies are unresolved.

    Basically the only way to to get this to work properly is by using the dynamically linked version of the extension library. This way it will use the correct version of the dependencies.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Tuesday, December 3, 2019 2:39 AM
  • When we use static link with the extension library ( we also link to MFC, does not matter statically or dynamically), there are multiple link errors, ...

    As far as I know, MFC extension libraries can only be DLLs. See https://docs.microsoft.com/en-us/cpp/build/extension-dlls?view=vs-2019
    Tuesday, December 3, 2019 8:34 AM
  • 1. Indeed, all pieces are built with the same version of Visual Studio (2017 or 2019)

    2. When we use default /Zc:wchar_t, both dynamic and static link between the application and custom library works fine: the problem comes up only with /Zc:wchar_t-.

    Thanks!

    Boris

    Tuesday, December 3, 2019 1:37 PM
  • 1. Indeed, all pieces are built with the same version of Visual Studio (2017 or 2019)

    2. When we use default /Zc:wchar_t, both dynamic and static link between the application and custom library works fine: the problem comes up only with /Zc:wchar_t-.

    Thanks!

    Boris

    1. I assume you're not mixing 2017/2019 built components?

    2. Give us a short example of a couple of linker errors you get.

    Tuesday, December 3, 2019 2:26 PM
  • error LNK2001: unresolved external symbol "public: virtual void __cdecl CGXControl::ReplaceSel(wchar_t const *)" (?ReplaceSel@CGXControl@@UEAAXPEB_W@Z)

    error LNK2001: unresolved external symbol "public: virtual void __cdecl CGXGridCore::OnTextNotFound(wchar_t const *)" (?OnTextNotFound@CGXGridCore@@UEAAXPEB_W@Z)

    error LNK2019: unresolved external symbol "public: __cdecl CGXUserAttribute::CGXUserAttribute(class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class ATL::ChTraitsCRT<wchar_t> > > const &)" (??0CGXUserAttribute@@QEAA@AEBV?$CStringT@_WV?$StrTraitMFC_DLL@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z) referenced in function "public: virtual int __cdecl CGridSample9View::GetStyleRowCol(unsigned long,unsigned long,class CGXStyle &,enum GXModifyType,int)" (?GetStyleRowCol@CGridSample9View@@UEAAHKKAEAVCGXStyle@@W4GXModifyType@@H@Z)

    Similar errors for all functions with wchar_t passed in.

    Tuesday, December 3, 2019 3:20 PM
  • Aren't the above errors coming from using a third-party component (i,e,, Objective Grid/MFC) that you did not build?



    • Edited by RLWA32 Tuesday, December 3, 2019 3:36 PM
    Tuesday, December 3, 2019 3:36 PM
  • No. Objective Grid is the MFC extension library mentioned above: both this library and executable are built with /Zc:wchar_t- on VS 2017. With dynamic link between exe and this library (or without "-") there are no link errors.
    Tuesday, December 3, 2019 4:00 PM
  • There must be something mismatched. Have you checked the names in the lib you're linking?

    See how to use dumpbin to check the decorated names.

    Tuesday, December 3, 2019 4:49 PM