Re: Linking errors after conversion from VS2003 to VS2005
- From: BK-Chicago <BKChicago@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 17 Aug 2006 14:23:01 -0700
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" <Tammam@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote.
I had a solution composed of managed/unmanaged C++ , C# projects. ItYou should always rebuild everything with the correct headers and libraries.
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.
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: __thiscallWhat does "Error 34" mean? Is that the 34th error you see? Why don't you
std::_Container_base::_Container_base(void)"
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<int> i; do_something_with(i); }
here, the ctor for std::vector<int> is 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
- References:
- Re: Linking errors after conversion from VS2003 to VS2005
- From: Holger Grund
- Re: Linking errors after conversion from VS2003 to VS2005
- Prev by Date: Bobby Mattappally or anyone else - calling CAsyncSocket Create in unmanaged C++ dll from managed C++ dll from C# app
- Next by Date: Passing none static member function as callback parameter to manag
- Previous by thread: Re: Linking errors after conversion from VS2003 to VS2005
- Next by thread: Re: Debug a C++ DLL from a C# Windows app in VS.NET2005
- Index(es):
Relevant Pages
|
