c++ - quimicos - Acerca del enlace dll inconsistente
tipos de enlaces covalentes (6)
El propósito de las declaraciones del preprocesador:
#ifdef _GUICTRLS
#define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
#define GUI_CTRLS_EXPORT __declspec(dllimport)
#endif
es asegurarse de que el archivo de cabecera declara la clase o función como __declspec (dllexport) en el .dll donde está definido, y como __declspec (dllimport) para cualquier otro .dll que pueda querer usarlo.
Para que esto funcione, _GUICTRLS se debe definir al compilar el archivo .dll de exportación y no se ha definido para ningún otro .dll. En general, se espera que _GUICTRLS se defina en las propiedades del proyecto, en C / C ++ -> Preprocesador -> Definiciones de preprocesador.
El error del compilador que está viendo generalmente ocurre porque _GUICTRLS no está definido para el proyecto que está exportando, o está definido para múltiples proyectos, por lo general como resultado de cortar un pegado de un proyecto a otro. También verá esto si _GUICTRLS está definido en un archivo de encabezado que se incluye en varios proyectos.
¿Cómo puedo eliminar esta advertencia de enlace? Puede ver el segmento de código que causa esta advertencia.
static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
//bla bla
// Exported DLL initialization is run in context of running application
extern "C" void WINAPI InitGuiCtrlsDLL()
{
// create a new CDynLinkLibrary for this app
new CDynLinkLibrary(GuiCtrlsDLL);
// nothing more to do
}
advertencia C4273: ''InitGuiCtrlsDLL'': inconsisten tll ligamiento
También exporté e importé definiciones, como:
#ifdef _GUICTRLS
#define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
#define GUI_CTRLS_EXPORT __declspec(dllimport)
#endif
Esa advertencia generalmente es causada por una definición duplicada de una función con diferente uso de dllimport. ¿Estás seguro de que no hiciste esto?
Hay múltiples posibilidades:
1) static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };
Utiliza AFX_EXTENSION_MODULE. Esto significa que está implementando una DLL de extensión MFC. Para tales extensiones dlls, debe definir el preprocesador _AFXEXT. Establezca esto en la configuración del compilador C ++ de su proyecto de Visual C ++
ver:
Cómo utilizar _declspec (dllexport) en una DLL de extensión MFC: http://support.microsoft.com/kb/128199
(Actualmente no puedo publicar más de 1 enlace porque mi reputación es inferior a 10. Agregaré 2 enlaces más importantes más adelante. Si esta es la solución, márquela como respuesta para acelerar el proceso;))
Como prometieron, aquí están los dos enlaces:
AFX_EXTENSION_MODULE Estructura: http://msdn.microsoft.com/en-us/library/sxfyk0zk.aspx
TN033: versión DLL de MFC: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx
2) Es probable que tengas una definición / declaración duplicada.
Observe que no está definiendo los símbolos exportados en un proyecto diferente. También limpie todos los archivos intermedios a mano y vuelva a compilar.
[CMake enlace DLL incoherente]
Encontré el siguiente problema + solución con el __declspec (dllexport) + __declspec (dllimport):
# # #CMakeLists.txt
add_defintions(-DMYLIB=1)
# The above was the solution...
# (MYLIB is used in the standard ifdef + define MYLIB_EXPORT syntax)
# Below: seems to get overruled by other directory''s headers:
set_source_files_properties( file1.h file2.h COMPILE_FLAGS "-DMYLIB=1")
Esto era molesto porque varias fuentes dicen que debe usar el comando ''set source file properties'' para obtener una mejor granularidad, pero el documento no está claro sobre lo que sucede con el archivo1.h''s declara cuando se lo incluye desde un directorio diferente ... mejor apegarse con add_definitions( -DMYLIB=1 )
por ahora!
Para detectar este problema: en su archivo Foo.cpp:
#include "export.h"
#if defined(MYLIB)
#if defined(OTHERLIB)
static_assert(0,"error, check your definitions!");
// OTHER depends on MY; can''t have both of these flags being set!
#endif
#endif
struct OTHER_EXPORT foo
{
};
Además de leer el mensaje de advertencia, preste atención a dónde ocurre si tiene varios proyectos como parte de un espacio de trabajo.
Perdí el tiempo buscando un problema en mi archivo DLL que compilaba y vinculaba correctamente. El espacio de trabajo también creaba la aplicación principal y mi error fue que inadvertidamente incluí un nuevo archivo fuente (DLL) en la lista de archivos de compilación de la aplicación .
El programa principal requiere el encabezado DLL mynewdll.h para importar cosas pero no requiere el archivo fuente mynewdll.cpp. (El código se ingresa en tiempo de ejecución con un archivo DLL.) Tengo la costumbre de incluir archivos de encabezado y código en proyectos como un par, y aquí es donde me he equivocado.
¡Hubiera detectado el error mucho antes si hubiera estado alerta y hubiera notado que el proyecto DLL se vinculó sin errores y fue el programa principal el que se quejó!
El código fuente y el proyecto de mi DLL no contenían errores y solo la forma en que intenté construir mi ejecutable era defectuosa.