CODEWITHSUNDEEP
c++visual-studio-2008visual-c++linker-errorssymbols
sctb
sctb

Reputation: 21

Unresolved external symbol due to VC9 compiler symbol name mismatch

I'm seeing the following error message when attempting to link a library in one project against another in the same solution:

CPTemplate.obj : error LNK2019: unresolved external symbol "public: long __thiscall MPADOFieldList::GetField(wchar_t *,struct Field * *)" (?GetField@MPADOFieldList@@QAEJPA_WPAPAUField@@@Z) referenced in function "public: virtual long __stdcall CCPTemplate::GetRootStorage(struct IMPRootStore * *)" (?GetRootStorage@CCPTemplate@@UAGJPAPAUIMPRootStore@@@Z)

Using 'dumpbin /symbols' on the static library that I'm linking against reveals a different symbol for the 'GetField' method:

?GetField@MPADOFieldList@@QAEJPA_WPAPAUADOField@@@Z (public: long __thiscall MPADOFieldList::GetField(wchar_t *,struct ADOField * *))

Clearly the difference is 'Field' vs. 'ADOField'. 'Field' is defined in a referenced header :

typedef interface ADOField Field;

The declaration of the 'GetField' method is as follows:

HRESULT GetField( BSTR  bstrFieldName,  Field**  rpField );

Upvotes: 2

Views: 281

Answers (1)

Ylisar
Ylisar

Reputation: 4291

This is almost certainly down to one of two things, eitherthe typedef being conditional, and for the lib it takes one branch while in the main project it takes the other. However, as the type resolves Field in the main project I have a more plausible theory. The header that contains the GetField declaration has a forward declaration for Field, the typedef however is not seen in this TU at all so it's assumed to be a type which will be defined elsewhere ( causing the first link ). In the library however the typedef is seen and correctly resolved to ADOField, causing the mismatch. The solution is to make sure that the typedef is seen in the TU that contains the definition for CCPTemplate::GetRootStorage.

Upvotes: 1

Related Questions