Über inkonsistente DLL-Verknüpfung

Wie kann ich Sie entfernen diesen link Warnung? Sie können sehen, code-segment, die Ursachen dieser Warnung.

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
    }

warning C4273: 'InitGuiCtrlsDLL' : inconsisten
t-dll linkage

Ich habe auch export-und import-Definitionen, wie:

#ifdef _GUICTRLS
   #define GUI_CTRLS_EXPORT __declspec(dllexport)
#else
   #define GUI_CTRLS_EXPORT  __declspec(dllimport)
#endif

InformationsquelleAutor der Frage baris.aydinoz | 2010-04-07

  1. 16

    Gibt es mehrere Möglichkeiten:

    1) static AFX_EXTENSION_MODULE GuiCtrlsDLL = { NULL, NULL };

    Verwenden Sie AFX_EXTENSION_MODULE. Dies bedeutet, dass Sie die Umsetzung einer MFC-Erweiterungs-DLL. Für solche Erweiterungs-dlls, die Sie haben zu definieren, die der Präprozessor _AFXEXT. Setzen Sie diese in der C++ - compiler-Einstellungen von Visual C++ - Projekt

    finden Sie unter:

    Wie Zu Verwenden von _declspec(dllexport) in einer MFC-Erweiterungs-DLL: http://support.microsoft.com/kb/128199

    (Momentan kann ich keine post mehr als 1 link, weil mein Ruf ist weniger als 10. Ich will hinzufügen, weitere 2 wichtige links später. Also, wenn das die Lösung ist, markieren Sie es als Antwort zur Beschleunigung des Prozesses 😉 )

    Wie versprochen, hier sind die zwei links:

    AFX_EXTENSION_MODULE Struktur: http://msdn.microsoft.com/en-us/library/sxfyk0zk.aspx

    TN033: MFC-DLL-Version: http://msdn.microsoft.com/en-us/library/hw85e4bb.aspx

    2) Es ist wahrscheinlich, dass Sie einen doppelten Definition/Erklärung.

    InformationsquelleAutor der Antwort Gökhan Akca

  2. 36

    Den Zweck der Präprozessor-Anweisungen:

    #ifdef _GUICTRLS 
   #define GUI_CTRLS_EXPORT __declspec(dllexport) 
#else 
   #define GUI_CTRLS_EXPORT  __declspec(dllimport) 
#endif

    ist, um sicherzustellen, dass der header-Datei deklariert die Klasse oder Funktion als __declspec(dllexport) in der .dll wo es definiert ist, und als __declspec(dllimport) für alle anderen .dll, die könnten es verwenden möchten.

    Damit dies funktioniert, _GUICTRLS muss definiert sein, wenn das kompilieren der Export .dll, und nicht definiert für alle anderen .dll. In der Regel würden Sie erwarten, dass _GUICTRLS definiert werden, die in den Projekteigenschaften unter C/C++ -> Präprozessor -> Präprozessor-Definitionen.

    Den compiler-Fehler, den Sie sehen, geschieht in der Regel, weil entweder _GUICTRLS ist nicht für das Projekt definiert, das tut den export, oder es wird definiert, für mehrere Projekte, in der Regel infolge von schneiden ein einfügen von einem Projekt zum anderen. Sie werden auch sehen, wenn _GUICTRLS ist definiert in der header-Datei enthalten ist, in mehreren Projekten.

    InformationsquelleAutor der Antwort Eric Thompson

  3. 2

    Diese Warnung ist in der Regel verursacht durch eine doppelte definition einer Funktion mit unterschiedlichen Verwendung des dllimport. Sind Sie sicher, dass Sie das nicht tun?

    InformationsquelleAutor der Antwort Matteo Italia

  4. 1

    [ CMake inkonsistente dll-Bindung ]

    Stiess ich auf das folgende Problem + Lösung mit dem __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")

    Dieser war ärgerlich, da eine Reihe von Quellen sagen, zur Nutzung der "set source file properties" - Befehl, um eine bessere Granularität, aber der doc ist nicht klar, was passiert, Datei1.h erklärt, wenn aus einem anderen Verzeichnis... besser stick mit add_definitions( -DMYLIB=1 ) für jetzt!

    Fangen dieses problem: in Ihrer Foo.cpp Datei: 

    #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 
{ 
};

    InformationsquelleAutor der Antwort peter karasev

  5. 1

    Neben dem Lesen der Warnmeldung, die darauf achten, wo es Auftritt wenn Sie mehrere Projekte haben, die als Teil eines Arbeitsbereichs.

    Ich verschwendet Zeit mit der Suche für ein problem, in meiner DLL die Kompilierung und Verlinkung korrekt. Der Arbeitsbereich wurde auch beim Bau der main-Anwendung und mein Fehler war, ich hatte versehentlich einen neuen (DLL) Quelle-Datei in der build-Datei-Liste von der Anwendung selbst.

    Benötigt das Hauptprogramm die DLL-header-mynewdll.h zu importieren, die Dinge aber nicht erforderlich, die source-Datei mynewdll.cpp. (Der code ist eingebracht, die zur Laufzeit mit einer DLL-Datei.) Ich habe die Angewohnheit, einschließlich header-und code-Dateien in Projekten als paar, und das ist, wo ich falsch gelaufen war.

    Hätte ich erkannt, der Fehler viel früher, wenn ich war wachsam und bemerkte, dass Sie das DLL-Projekt verlinkt mit keine Fehler und es war das main-Programm, das sich beschwert!

    Meine DLL source code und Projekt Fehler war frei und es war nur die Art und Weise, die ich versuchte zu bauen, meine ausführbare Datei, die fehlerhaft war.

    InformationsquelleAutor der Antwort user3070485

  6. 0

    Sehen, dass Sie nicht der Definition der exportierten Symbole in einem anderen Projekt. Reinigen auch alle dazwischen liegenden Dateien von hand kompilieren.

    InformationsquelleAutor der Antwort damian

Schreibe einen Kommentar