Нерешенный внешний символ из-за несоответствия имени символа компилятора VC9 - PullRequest
Новая
       38

Нерешенный внешний символ из-за несоответствия имени символа компилятора VC9

2 голосов
/ 29 марта 2012

Я вижу следующее сообщение об ошибке при попытке связать библиотеку в одном проекте с другим в том же решении: 

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)

Использование 'dumpbin / symbols' для статической библиотеки, которую ясвязывание с показывает другой символ для метода «GetField»: 

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

Очевидно, что разница «Поле» и «ADOField».Поле определяется в указанном заголовке: 

typedef interface ADOField Field;

Объявление метода GetField выглядит следующим образом: 

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

1 Ответ

1 голос
/ 29 марта 2012

Это почти наверняка связано с одной из двух вещей, либо typedef является условным, и для lib это занимает одну ветвь, а в основном проекте - другую.Однако, поскольку тип разрешает Field в основном проекте, у меня появляется более правдоподобная теория.Заголовок, содержащий объявление GetField, имеет прямое объявление для Field, однако typedef вообще не виден в этом TU, поэтому предполагается, что это тип, который будет определен в другом месте (вызывая первую ссылку).Однако в библиотеке typedef виден и правильно разрешен до ADOField, что вызывает несоответствие.Решение состоит в том, чтобы убедиться, что typedef виден в TU, который содержит определение для CCPTemplate::GetRootStorage.

...