DLL enlazando a bibliotecas estáticas

Tenemos un proyecto que es un ejecutable, que carga archivos DLL en tiempo de ejecución como complementos.

Estamos tratando de hacer un nuevo complemento en el que haya muchas dependencias de biblioteca, y algunas de esas dependencias son la misma biblioteca pero diferentes versiones a las que se vinculan otros complementos.

Debido a que las bibliotecas dependen de diferentes complementos en diferentes versiones, me gustaría vincular / construir de forma estática cualquier dependencia en el nuevo complemento, de esa manera no pueden entrar en conflicto con las dependencias del complemento anterior. Por lo que sé, no es necesario exportar nada en las dependencias del complemento, simplemente son utilizados por el complemento.

¿Es posible hacer esto?

He intentado comstackr todas las librerías estáticas en Visual Studio como bibliotecas estáticas con el tiempo de ejecución configurado en DLL multiproceso con el indicador / MD, pero cuando bash comstackr dynamiclibB.dll, obtengo errores de vinculador. Si configuro dynamiclibB para construir como una biblioteca estática, no tiene los errores del enlazador.

No he intentado vincular newplugin.dll a la versión de biblioteca estática de dynamiclibB todavía, pero creo que tengo exactamente la misma situación, por lo que no veo ninguna razón por la que funcione allí donde no tenga un nivel inferior.

De todos modos, no quiero crear dynamiclibB como una biblioteca estática, ya que sería bueno poder actualizar newplugin.dll sin incluir dynamiclibB.dll si no se ha cambiado, como en, para desacoplar el proceso de actualización. Esta línea de razonamiento sugiere que debería tener .dlls para todo, pero creo que los conflictos de versiones son lo que me preocupa.

No puedo comstackr los complementos como bibliotecas estáticas, ya que deben cargarse en tiempo de ejecución.

Absolutamente todo se está construyendo en modo de liberación por ahora, para evitar esa complicación.

¿Qué me estoy perdiendo?

Un bash de un diagtwig que podría ayudar a entender la situación:

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

Actualización: Proporcionar más información ahora que sé lo que está sucediendo y saber que detalles más específicos son realmente relevantes. Así que la biblioteca A, representada por dynamiclibA y staticlibA fue zlib. La biblioteca que estábamos comstackndo (dynamiclibB) para usar en el newplugin era PoDoFo. Los mensajes de error que recibimos fueron:

 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 

Poniendo el rest en una respuesta.

En mi pregunta, slibc.lib era libpng. Libpng también requiere zlib, pero lo construye desde la fuente dentro de su solución. Pudimos utilizar la salida de ese proyecto de la manera que deseamos, como en, zlib.lib creado con el indicador / MD, sin errores de enlace.

También logramos averiguar por qué ocurrió este problema: otra pregunta de stackoverflow fue muy relevante: https://stackoverflow.com/a/6559315/78823

Resulta que zlib tiene un #define ZLIB_WINAPI que definió la convención de llamada como STDCALL, que no entiendo, pero causó los errores del vinculador. La otra respuesta sugiere eliminar la definición, y supongo que eso es lo que libpng hizo con su proyecto zlib.

Supongo que la razón por la que los errores del vinculador solo ocurrieron al comstackr el .dll y desaparecieron al comstackr el .lib es porque (corríjame si me equivoco, no entiendo completamente esto), compile un .lib doesn En realidad no se vincula a las funciones requeridas, por lo que habría sido simplemente pasar los errores del enlazador al siguiente nivel; Creo que habríamos visto los mismos errores (pero en diferentes objs / proyectos quizás) al comstackr newplugin.dll, pero no llegamos lo suficientemente lejos como para verificarlo antes de intentar otras cosas.