Linking errors after conversion from VS2003 to VS2005

[Tammam]

Hello All,

I had a solution composed of managed/unmanaged C++ , C# projects. It builds
with no problem in VS2003 but after converting the solution to VS2005 i get
many linking errors such as LNK2020 LNK2028. Below is a little bit of the
error report.

Error 34 error LNK2020: unresolved token (0A000029) "public: __thiscall
std::_Container_base::_Container_base(void)"
(??0_Container_base@std@@$$FQAE@XZ) UnmanagedResiprocateController.obj
Error 35 error LNK2028: unresolved token (0A000023) "public: __thiscall
std::_Container_base::_Container_base(void)"
(??0_Container_base@std@@$$FQAE@XZ) referenced in function "public:
__thiscall std::_Tset_traits<class resip::MergedRequestKey,struct
std::less<class resip::MergedRequestKey>,class std::allocator<class
resip::MergedRequestKey>,0>::_Tset_traits<class
resip::MergedRequestKey,struct std::less<class resip::MergedRequestKey>,class
std::allocator<class resip::MergedRequestKey>,0>(struct std::less<class
resip::MergedRequestKey>)"
(??0?$_Tset_traits@VMergedRequestKey@resip@@U?$les s@VMergedRequestKey@resip@@@std@@V?$allocator@VMer gedRequestKey@resip@@@4@$0A@@std@@$$FQAE@U?$less@V MergedRequestKey@resip@@@1@@Z) SipStackAccessor.obj
Error 36 error LNK2028: unresolved token (0A000029) "public: __thiscall
std::_Container_base::_Container_base(void)"
(??0_Container_base@std@@$$FQAE@XZ) referenced in function "protected:
__thiscall std::_Vector_val<class resip::NameAddr *,class
std::allocator<class resip::NameAddr *::_Vector_val<class resip::NameAddr
*,class std::allocator<class resip::NameAddr *(class std::allocator<class
resip::NameAddr *>)"
(??0?$_Vector_val@PAVNameAddr@resip@@V?$allocator@ PAVNameAddr@resip@@@std@@@std@@$$FIAE@V?$allocator @PAVNameAddr@resip@@@1@@Z) SIPDataProcessing.obj

Any idea whats the possible cause of this problem. I used many ideas I found
online but none worked.

Your help is really appreciate

Thanks in advance,

Tammam

[Holger Grund]

"Tammam" <Ta****@discussions.microsoft.comwrote

I had a solution composed of managed/unmanaged C++ , C# projects. It
builds
with no problem in VS2003 but after converting the solution to VS2005 i
get
many linking errors such as LNK2020 LNK2028. Below is a little bit of the
error report.

You should always rebuild everything with the correct headers and libraries.
Unless you did anything evil (patching headers, overriding default
directories
for libs & headers, switches like /Zl or /NODEFAULTLIB or incompatible
/M[D|T] /D_STATIC_CPPLIB switches etc.) you should be fine.

Error 34 error LNK2020: unresolved token (0A000029) "public: __thiscall
std::_Container_base::_Container_base(void)"

What does "Error 34" mean? Is that the 34th error you see? Why don't you
show use the first one?

It effectively means that the linker cannot resolve the MemberRef for
std::_Container_base default constructor.

The typical way to solve such a problem methodically is to
determine where it is used, and - if the use is correct -
where it is defined and why the definition is not lifted.

You can always use dumpbin /SYMBOLS or ildasm /out on your object files
to see where the reference comes from (and actually the linker should give
you an indication).

Looking at the headers many of the containers are derived from
_Container_base (surprise, surprise). That's probably where the
reference comes from. E.g.:

void foo() { std::vector<inti; do_something_with(i); }

here, the ctor for std::vector<intis instantiated, which in turn
instantiates the default ctor for std::_Vector_val<>, which in
turn references the default ctor of std::_Container_base.

Looking at the definition in xutility there are three possible
variants:
1) _HAS_ITERATOR_DEBUGGING (default for _DEBUG)
2) _DEBUG && !_HAS_ITERATOR_DEBUGGING
3) NDEBUG

For the former two the default ctor is defined inline but the
class is marked as _CRTIMP2_PURE. IIRC, that resolves
to __declspec(dllimport) depending on the C++ linkage
model (/MT v. /MD & _STATIC_CPPLIB macro) or
to nothing for /clr:pure.

That also means that the definition should be included in
the debug version of the native C++ DLL library (msvcrtd.lib)
but not in the release version (msvcrt.lib). Since /clr implies
/MD, you should link with either one of these.

All that being said, I have no idea what your problem is.
I suspect it's a bogus /Zl or /NODEFAULTLIB somewhere.

If you want anyone to help you, I'm afraid you need to give us
much more information (such as the command lines used for
your build - compiler and linker - and any linker warnings and
errors you see).

-hg

[BK-Chicago]

Could you also answer if VS2005 was installed after the installation of
VS2003 or the other way around?

If you installed VS2003 before VS2005, i would recommend uninstalling both
and then installing VS2003 before installing VS2005.
"Holger Grund" wrote:

"Tammam" <Ta****@discussions.microsoft.comwrote

I had a solution composed of managed/unmanaged C++ , C# projects. It
builds
with no problem in VS2003 but after converting the solution to VS2005 i
get
many linking errors such as LNK2020 LNK2028. Below is a little bit of the
error report.

You should always rebuild everything with the correct headers and libraries.
Unless you did anything evil (patching headers, overriding default
directories
for libs & headers, switches like /Zl or /NODEFAULTLIB or incompatible
/M[D|T] /D_STATIC_CPPLIB switches etc.) you should be fine.

Error 34 error LNK2020: unresolved token (0A000029) "public: __thiscall
std::_Container_base::_Container_base(void)"

What does "Error 34" mean? Is that the 34th error you see? Why don't you
show use the first one?

It effectively means that the linker cannot resolve the MemberRef for
std::_Container_base default constructor.

The typical way to solve such a problem methodically is to
determine where it is used, and - if the use is correct -
where it is defined and why the definition is not lifted.

You can always use dumpbin /SYMBOLS or ildasm /out on your object files
to see where the reference comes from (and actually the linker should give
you an indication).

Looking at the headers many of the containers are derived from
_Container_base (surprise, surprise). That's probably where the
reference comes from. E.g.:

void foo() { std::vector<inti; do_something_with(i); }

here, the ctor for std::vector<intis instantiated, which in turn
instantiates the default ctor for std::_Vector_val<>, which in
turn references the default ctor of std::_Container_base.

Looking at the definition in xutility there are three possible
variants:
1) _HAS_ITERATOR_DEBUGGING (default for _DEBUG)
2) _DEBUG && !_HAS_ITERATOR_DEBUGGING
3) NDEBUG

For the former two the default ctor is defined inline but the
class is marked as _CRTIMP2_PURE. IIRC, that resolves
to __declspec(dllimport) depending on the C++ linkage
model (/MT v. /MD & _STATIC_CPPLIB macro) or
to nothing for /clr:pure.

That also means that the definition should be included in
the debug version of the native C++ DLL library (msvcrtd.lib)
but not in the release version (msvcrt.lib). Since /clr implies
/MD, you should link with either one of these.

All that being said, I have no idea what your problem is.
I suspect it's a bogus /Zl or /NODEFAULTLIB somewhere.

If you want anyone to help you, I'm afraid you need to give us
much more information (such as the command lines used for
your build - compiler and linker - and any linker warnings and
errors you see).

-hg