Ich portiere gerade eine große C ++ - Anwendung von Linux (gcc) nach Windows (Visual C ++ 2008) und habe Linker-Probleme mit Plugins. Unter Linux stellte dies kein Problem dar, da .so die Laufzeitsymbolsuche unterstützt, aber dll scheint dies nicht zu unterstützen.
Einige Hintergrundinformationen: Die Anwendung (der Host), die eine Skriptumgebung hostet, stellt Schnittstellen zu Plugins (gemeinsam genutzte Bibliotheken, die zur Laufzeit von Script-API-Aufrufen geladen werden) bereit, sodass der Host und die Skripting-API ohne Neukompilierung der Hostanwendung erweitert werden können. Unter Linux ist es nur eine Frage der Header der Host-Anwendung in der Plugin-Quelle, aber unter Windows empfange ich Linker-Fehler. Ich bin mir nicht sicher, was genau ich mit Visual C ++ verknüpfen muss, um diese Symbole aufzulösen.
Eine unserer Abhängigkeiten (open source, LGPL) enthält Präprozessor-Deklarationen, die dazu verwendet werden, __declspec (dllexport) und __declspec (dllimport) in die Header einzufügen. Einige frühere Recherchen deuten darauf hin, dass ich dies ebenfalls tun muss, aber ich möchte sicher sein, bevor ich eine ganze Reihe von Kernüberschriften modifiziere. (Ich war früher in der Lage, dies an MinGW zu arbeiten, aber wir haben entschieden, dass die Unterstützung von Visual Studio eine Voraussetzung für diese Art von kommerziellen Projekten ist.)
Meine Frage kurz und knapp: Wie verknüpfe ich Laufzeit-geladene DLLs mit einer Host-Exe in Visual C ++?
Bearbeiten: Um das Problem anhand eines Beispiels zu verdeutlichen, habe ich eine Klasse in meiner Hostanwendung, Objekt , die den Basistyp eines Objekts darstellt, auf das ein Skript zugreifen kann. In meinen Plugins habe ich eine Reihe von Klassen, die Object erweitern, um andere Funktionen auszuführen, wie beispielsweise die Integration von Netzwerkunterstützung oder neuer visueller Elemente. Das bedeutet, dass meine DLL mit Symbolen in der Host-Exe verknüpft werden muss, und ich bin nicht sicher, wie das geht.
Was meinst du mit "Laufzeit Symbol Lookup"? Meinst du das Laden von Bibliotheken mit dlopen und dlsym und usw. ? Die Entsprechungen in Windows heißen LoadLibrary und GetProcAddress .
In Windows exportieren Sie keine Symbole aus einer ausführbaren Datei. Sie sollten sie nur aus einer DLL exportieren. Der richtige Weg, um Ihr Problem zu lösen, ist, rearchitect, so dass die exportierten Symbole in einer DLL sind, die die ausführbare und andere Plugin-DLLs mit verknüpfen können.
Das geht nicht, einfach. Der Windows-Loader ist nicht dafür ausgelegt, Symbole aus einer EXE zu exportieren und sie an Symbole in einer DLL zu binden.
Ein Muster, das ich gesehen habe, ist der DLL-Export einer bestimmten Funktion, die das EXE aufruft. Es nimmt als Parameter eine Struktur an, die Adressen von Funktionen in der EXE enthält, die die DLL aufruft.
Wie 1800 INFORMATION sagt, mach es nicht so. Verschieben Sie das Objekt aus der ausführbaren Datei in eine "dritte" DLL. Verknüpfen Sie die Plugins und die ausführbare Datei damit.
Ich habe dasselbe implementiert und eine Plugin-Bibliothek erstellt, die sowohl unter Linux als auch unter Windows erstellt werden kann.
Die Lösung unter Linux ist die Verwendung der Option -rdynamic in der gcc-Befehlszeile. Dies exportiert alle Symbole in der Hauptdatei, so dass ein Plugin sie beim Laden finden kann.
Unter Windows besteht die Lösung darin, __declspec (dllexport) vor der Definition dieser Funktionen in der exe einzufügen, die die DLLs verwenden sollen. Die Kompilierung erstellt eine .lib-Datei für die zu verknüpfenden DLLs. Sicher arbeitet unter Visual Studio 2008. Verwandter Beitrag: Ссылка
Tags und Links c++ dll plugins visual-studio-2008 visual-c++