[gcc] Symbolexport erzwingen

Das Gurke

Vorab: Ich arbeite nicht mit makefiles, sondern lasse Code::Blocks die "dreckige" Arbeit erledigen. Das Projekt um das es sich dreht soll Platformübergreifend kompilierbar sein, möglichst auch per mingw.

Das Problem: Ich bastele momentan gerade an einer sehr einfachen Plugin API, im wesentlichen will ich nur C Funktionen aus Shared Objects / DLLs aufrufen können. Das funktioniert auch ohne Probleme.

Nun müssen diese Plugins aber auch auf Funktionalitäten des Plugin Hosts zugreifen können. Unter Windows hat mich das nicht direkt vor Probleme gestellt, ich hab regel das halt über das schon oft (zumindest unter Windows) erprobte Export Makro Prinzip gelöst:

#   if COMPILER == COMPILER_GNUC
#       define _WoRDExport  __attribute__ ((visibility("default")))
#       define _WoRDPrivate __attribute__ ((visibility("hidden")))
#   // Exporting with msvc
#   else
#       define _WoRDExport __declspec(dllexport)
#       define _WoRDPrivate
#   endif

Unter Windows ist alles wunderbar. Unter Linux tauchen die mit _WoRDExport markierten Klassen aber irgendwie nicht auf ... Der Linker zeigt Fehler (findet halt die exportierten Klassen / Funktionen nicht) und ich habe auch schonmal mit "nm -C -D PluginHost" nachgeprüft: Meine Exportierten Sachen tauchen im kompilierten Plugin Host nicht auf. Kein Wunder also, dass die Plugins dagegen nicht linken wollen.

Nun ist diese Hostanwendung keine Shared Library, sondern ein "Konsolenprojekt". Und ich vermute, dass das irgendwie daran hängt Nur gibt es ja auch Projekte, die das anscheinend hinbekommen.

Die komprimierte Frage: Wie kann ich den gcc dazu zwingen diese Klassen und Methoden zu veröffentlichen ohne den Code als shared object zu erstellen? Ich habs auch schon mit __attribute__((dllexport)) & __declspec(dllexport) versucht, weil diverse Seiten behaupteten das würde helfen. Hats aber nicht

Das Gurke schrieb:

Ich habs auch schon mit __attribute__((dllexport)) & __declspec(dllexport) versucht, weil diverse Seiten behaupteten das würde helfen. Hats aber nicht

Das funktioniert ja auch nur unter Windows.

Ich weiß nicht, ob sich das Problem lösen lässt, da das linken von dynamischen Bibliotheken unter Linux vollkommen anders Funktioniert, als unter Windows.

Ich würde folgenden Work-Around vorschlagen:

Übergib deinem Plugin die Funktionen im "Host"-Programm, die das Plugin aufrufen können soll, als Funktionspointer. Das sollte funktionieren.

Das Gurke schrieb:

Die komprimierte Frage: Wie kann ich den gcc dazu zwingen diese Klassen und Methoden zu veröffentlichen ohne den Code als shared object zu erstellen?

wenn du mit host die ausführbare datei meinst, die das plugin läd, musst du diese mit der linker option -export-dynamic compilieren. damit werden alle symbole der exe datei exportiert.
mit hilfe der visibility attribute kannst du den export dann erst pro symbol angeben. ohne -export-dynamic funktionieren die visibility attribute nur in dynamischen bibliotheken.