Неразрешенный внешний символ ATL :: IAtlMemMgr после обновления до Visual Studio 2019 - PullRequest
Новая
       79

Неразрешенный внешний символ ATL :: IAtlMemMgr после обновления до Visual Studio 2019

0 голосов
/ 28 января 2020

В настоящее время я обновляю наш исходный код с VS2012 до VS2019. Один проект, который использует MF C, не связывается успешно:

фатальная ошибка LNK1120: 4 неразрешенных внешних кода

ошибка LNK2001: неразрешенный внешний символ "publi c: void * __cdecl ATL :: IAtlMemMgr :: Allocate (без знака __int64) «ссылка в функции» publi c: виртуальная структура ATL :: CStringData * __cdecl ATL :: CAtlStringMgr :: Allocate (int, int) "

ошибка LNK2001 : неразрешенный внешний символ "publi c: void __cdecl ATL :: IAtlMemMgr :: Free (void *)", на который есть ссылка в функции "publi c: виртуальный void __cdecl ATL :: CAtlStringMgr :: Free (struct ATL :: CStringData * ) "

ошибка LNK2001: неразрешенный внешний символ" publi c: void * __cdecl ATL :: IAtlMemMgr :: Reallocate (void *, unsigned __int64) ", на который ссылается функция" publi c: виртуальная структура ATL :: CStringData * __cdecl ATL :: CAtlStringMgr :: Reallocate (struct ATL :: CStringData *, int, int) "

ошибка LNK2001: неразрешенный внешний символ" publi c: виртуальная структура ATL :: CStringData * __cdecl ATL :: IAtlString Mgr :: Reallocate (struct ATL :: CStringData *, int, int) "

Мы строим с помощью многобайтового набора символов (MBCS). Моей первой мыслью было, что нам не хватает библиотек MBCS. Но, как уже упоминалось здесь , библиотеки устанавливаются по умолчанию «при выборе MF C и поддержке ATL».

Я добавил atlbase.h в коде и добавил atls.lib вручную в качестве дополнительной зависимости, но это не решило проблему.

Как определить, какая библиотека отсутствует?

Редактировать 1: Давайте рассмотрим atlmem.h : 

    __interface __declspec(uuid("654F7EF5-CFDF-4df9-A450-6C6A13C622C0")) IAtlMemMgr{
    public:
        _Ret_maybenull_ _Post_writable_byte_size_(nBytes) void* Allocate(_In_ size_t nBytes) throw();

Как Насколько я вижу, это один из символов, который не найден. Как видно из ключевого слова __ interface , оно неявно делает функции чисто виртуальными. Такого рода ошибки компоновщика могут быть вызванными объявлениями не чисто виртуальных функций.

Может ли быть ошибка, из-за которой функции в интерфейсе __ не являются чисто виртуальными?

1 Ответ

0 голосов
/ 30 января 2020

После исключения почти всех исходных файлов и комментирования большого количества функций я увидел, что ошибки компоновщика связаны с <afxwin.h>. Перемещение <afxwin.h> в начало каждого исходного файла позволило удалить ошибки компоновщика. Однако мне интересно знать, почему компиляция с VS2012 дает другое поведение по сравнению с VS2019.

...