unresolved external symbol из-за того, что в lib файле, который использует exe, не определён сторонний класс

@Jodi Redlot · Регистрация: 25.04.2017

Author24 — интернет-сервис помощи студентам

Прежде всего, весь код в архиве. А тут лишь краткое описание происходящего.

DLL:
- определён класс CFileSystem
- собирается без ошибок

LIB:
- определён класс VGUI
- используются методы CFileSystem
- собирается без ошибок

EXE:
- линкуется LIB
- получается поинтер на переменную типа CFileSystem и передаётся в новую переменную типа VGUI
- при сборке жалуется на неразрешённые внешние символы: методы класса CFileSystem, в том числе конструктор. Ну это понятно. Причём ошибка как в obj-файле EXE, так и в obj-файле LIB

Можно ли что-то предпринять в данной ситуации? В LIB CFileSystem необходим, но при этом он не должен быть определён там: ему там просто не место.

PS. Решение называется так, как называется, потому что изначально я предпринимал попытки экспорта классов из DLL в EXE. Поняв, что ничего у меня без фабричного метода не выйдет (а его реализовывать я не хочу), остановился на использовании статичной библиотеки

@TheCalligrapher · 27.07.2020, 22:02

Если ваш LIB должен линковаться именно в EXE (как вы говорите), и вы хотите напрямую работать с методами CFileSystem в EXE (как у вас сейчас), то тогда весь класс CFileSystem должен быть объявлен как dllexport при компиляции DLL и dllimport при компиляции всего остального. У вас этого не сделано. Неудивительно, что за пределами DLL этот класс не линкуется. Он просто не экспортируется из DLL вообще.

Другое дело, если бы LIB линковался только в DLL...

---

Для чего предназначен интерфейс IFileSystem? Он выглядит так, как будто именно через него должны были решаться вопросы связывания (как это делается в COM, вместо вашей нынешней прямой линковки). Но вы через него вообще нигде даже и не пытаетесь работать. Зачем вы тогда вообще заводили IFileSystem?

@Jodi Redlot · 28.07.2020, 04:48 **[ТС]**

IFileSystem нужен в конечном проекте для того, чтобы как раз не возникало ошибок с внешними символами. IFileSystem, в свою очередь, имеет базовым классом IBase и складируется в vector<IBase*>interfaces вместе с остальными интерфейсами. Доступ к интерфейсу из другого модуля осуществляется через экспортную функцию. Кину код уж для наглядности.

C++

__declspec(dllexport) IBase* GetInterface(string name) {
        for (InterfaceInfo_t* i : interfaces)
            if (i->name._Equal(name)))
                return i->pointer;
 
        if (gLog != nullptr)
            gLog->warning("Interface named \"%s\" isn't found in \"%s\" module", name.c_str(), GetModuleName().c_str());
        else
            ErrorMsgBox("Interface named \"%s\" isn't found in \"%s\" module", name.c_str(), GetModuleName().c_str());
    }

В конечном проекте по итогу будет тоже самое как и в ClassExport, только вместо EXE-шника, LIB-а будет линковаться к другим DLL, где используется GUI. Но в LIB-е же необходимо работать с CFileSystem из filesystem.dll, с CLogиз в engine.dll, и ещё с парой классов.

По поводу dllexport и dllimport: с ними ситуация не меняется и даже становится хуже. Прикрепил скриншоты: 1) мои родные ошибки; 2) ошибки при использовании dllexport/dllimport

Речь ведь только об этом?

C++

1 2	class __declspec(dllexport) CFileSystem {... //DLL class __declspec(dllimport) CFileSystem {... //LIB, EXE

@TheCalligrapher · 28.07.2020, 05:57

Сообщение от Jodi Redlot

IFileSystem нужен в конечном проекте для того, чтобы как раз не возникало ошибок с внешними символами.

Это прекрасно, но пока что в вашем коде он не используется "чтобы как раз не возникало ошибок с внешними символами". Ваш код напрямую работает с CFileSystem. А IFileSystem в этом никак не участвует.

Сообщение от Jodi Redlot

Речь ведь только об этом?

C++

1 2	class __declspec(dllexport) CFileSystem {... //DLL class __declspec(dllimport) CFileSystem {... //LIB, EXE

Да, именно. Но что именно у вас там теперь понаписано из этого огрызка не ясно.

---

Я чисто ради эксперимента переобъявил ваш класс как

C++

class 
#ifdef EXPORTDLL_EXPORTS
  __declspec(dllexport)
#else
  __declspec(dllimport)
#endif
CFileSystem : public IFileSystem {
  ...

и у меня все прекрасно слинковалось.

---

Уточнение: для этого мне еще понадобилось подключить библиотеку импорта DLL. Где у вас в коде это подключение? У вас есть

C++

1	#pragma comment(lib, "ExportLIB.lib")

А для ExportDLL.lib где у вас аналогичное подключение???

(И что за странная манера использовать #pragma comment? В Visual Studio у вас в проектах есть References именно для того, чтобы не заниматься подобной фигней.)

@Jodi Redlot · 28.07.2020, 06:14 **[ТС]**

После подключения ExportDLL.lib всё слинковалось и заработало как надо. Спасибо вам большое.

А либу я приконтачил через #pragma comment чисто для наглядности. В конечном проекте я, конечно, таким не балуюсь.

@TheCalligrapher Вездепух 11695 / 6374 / 1724 Регистрация: 18.10.2014 Сообщений: 16,068
	27.07.2020, 22:02	2
	Если ваш LIB должен линковаться именно в EXE (как вы говорите), и вы хотите напрямую работать с методами `CFileSystem` в EXE (как у вас сейчас), то тогда весь класс `CFileSystem` должен быть объявлен как `dllexport` при компиляции DLL и `dllimport` при компиляции всего остального. У вас этого не сделано. Неудивительно, что за пределами DLL этот класс не линкуется. Он просто не экспортируется из DLL вообще. Другое дело, если бы LIB линковался только в DLL... --- Для чего предназначен интерфейс `IFileSystem`? Он выглядит так, как будто именно через него должны были решаться вопросы связывания (как это делается в COM, вместо вашей нынешней прямой линковки). Но вы через него вообще нигде даже и не пытаетесь работать. Зачем вы тогда вообще заводили `IFileSystem`? 0

@Jodi Redlot Developing a game engine 0 / 0 / 0 Регистрация: 25.04.2017 Сообщений: 87
	28.07.2020, 06:14 [ТС]	5
	После подключения ExportDLL.lib всё слинковалось и заработало как надо. Спасибо вам большое. А либу я приконтачил через #pragma comment чисто для наглядности. В конечном проекте я, конечно, таким не балуюсь. 0