DLL-ссылка на статические библиотеки

Question

У нас есть проект, который является исполняемым файлом, который загружает файлы DLL во время выполнения в виде плагинов.

Мы пытаемся создать новый подключаемый модуль, в котором есть много зависимостей между библиотеками, и некоторые из этих зависимостей - это одна и та же библиотека, но разные версии, к которым подключаются другие плагины.

Поскольку библиотеки зависят от разных плагинов в разных версиях, я хотел бы статически связывать/строить любые зависимости в новом плагине - таким образом они не могут конфликтовать со старыми зависимостями плагина. Насколько я знаю, ничто в зависимостях плагина не нужно экспортировать, они просто используются плагином.

Возможно ли это?

Я попытался создать все статические библиотеки в визуальной студии как статические библиотеки с временем выполнения, установленным в многопоточную DLL с флагом/MD, но когда я пытаюсь построить dynamiclibB.dll, я получаю ошибки компоновщика. Если я устанавливаю dynamiclibB для сборки как статической библиотеки, он не имеет ошибок компоновщика.

Я еще не пробовал связывать newplugin.dll со статической библиотекой версии dynamiclibB, но я думаю, что у меня точно такая же ситуация, поэтому я не вижу причин, почему она будет работать там, где она не будет на одном уровне вниз ,

Я не хочу строить dynamiclibB как статическую библиотеку в любом случае, так как было бы хорошо иметь возможность обновлять newplugin.dll без включения dynamiclibB.dll, если он не был изменен, как и в, чтобы отделить обновления. Эта линия рассуждений подсказывает, что я должен иметь .dll для всего, но конфликты версий беспокоят меня, я думаю.

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

Абсолютно все в настоящее время строится в режиме выпуска, чтобы избежать этого осложнения.

Что мне не хватает?

Попытка диаграммы, которые могли бы помочь разобраться в ситуации:

  program.exe 
       | 
     ________________ 
     |    | 
    oldplugin.dll  newplugin.dll 
     |    | 
dynamiclibA.dll  dynamiclibB.dll 
         | 
      _________________________ 
      |    |   | 
    staticlibA.lib slibC.lib slibD.lib 

Update: Предоставление больше информации теперь, когда я знаю, что происходит, и знаю, что более конкретные детали на самом деле являются актуальными. Итак, библиотека A, представленная dynamiclibA и staticlibA, была zlib. Библиотека, которую мы собирали (dynamiclibB) для использования в newplugin, была PoDoFo. сообщения об ошибках, которые мы получили, были:

Error 19 error LNK2001: unresolved external symbol 
_deflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 20 error LNK2001: unresolved external symbol 
_inflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 21 error LNK2001: unresolved external symbol 
_inflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngread.obj) podofo_shared Error 22 error LNK2001: unresolved external symbol 
_deflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 23 error LNK2001: unresolved external symbol 
_deflate E:\Work\podofo_bin\src\libpng16.lib(pngwutil.obj) podofo_shared Error 24 error LNK2001: unresolved external symbol 
_deflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 25 error LNK2001: unresolved external symbol 
_deflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngwrite.obj) podofo_shared Error 26 error LNK2001: unresolved external symbol 
_inflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 27 error LNK2001: unresolved external symbol 
_inflateInit_ E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared Error 28 error LNK2001: unresolved external symbol 
_inflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 29 error LNK2001: unresolved external symbol 
_inflate E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared 

Положив остальное в ответ.

Answer 1

В моем вопросе slibc.lib был libpng. Libpng также требует zlib, но он строит его из источника внутри своего решения. Мы могли использовать выход этого проекта так, как мы хотели, например, zlib.lib, построенный с флагом/MD, без ошибок связывания.

Мы также удалось выработать почему произошла эта проблема: другой StackOverflow вопрос очень актуален: https://stackoverflow.com/a/6559315/78823

Оказывается, что Zlib имеет #define ZLIB_WINAPI, который определил соглашение вызова будет STDCALL, который я не понимаю, но это вызвало ошибки компоновщика. Другой ответ предлагает удалить определение, и я полагаю, это то, что сделал libpng с его проектом zlib.

Я предполагаю, что причина, по которой ошибки компоновщика возникли только при создании .dll и исчезли при построении .lib, - это потому что (исправьте меня, если я ошибаюсь, я не совсем понимаю это), постройте a .lib фактически не выполняет привязки к требуемым функциям, поэтому просто передавал бы ошибки компоновщика на следующий уровень; Я думаю, что при компиляции newplugin.dll мы бы увидели те же ошибки (но, возможно, в разных объектах/проектах), но мы не получили достаточно много, чтобы проверить это, прежде чем мы пробовали другие вещи.