Ich habe eine plattformübergreifende C ++ - Anwendung, die in mehrere gemeinsam genutzte Bibliotheken unterteilt ist und zusätzliche Funktionen aus gemeinsam genutzten Plug-in-Bibliotheken lädt. Die Plugin-Bibliotheken sollten in sich geschlossen sein und von sich aus funktionieren, ohne Kenntnis oder Abhängigkeit von der aufrufenden Anwendung.

Eines der Plugins enthält kopierten Code aus der Hauptanwendung, dh Symbolnamen, die mit denen in der Engine identisch sind. (Ja, ich weiß, dass dies im Allgemeinen ein Nein-Nein ist, aber zu der Zeit, als das Plugin geschrieben wurde, war die Engine eine monolithische Binärdatei und konnte keine Bibliotheken gemeinsam nutzen.) Unter Windows läuft alles einwandfrei. Unter Linux gab es Segfaults. Beim Aufrufen von Funktionen im doppelten Klassennamen trat der Stack-Trace des Fehlers im Plugin auf. Es schien ein Ergebnis der Engine und des Plugins zu sein, die leicht unterschiedliche Versionen des gemeinsam genutzten Codes hatten (einige Klassenfunktionen wurden im Plugin auskommentiert). Es war, als würde das Plugin seine Symbole zur Laufzeit mit der Engine verknüpfen, anstatt mit der eigenen. Wir haben das Problem durch Ändern der "behoben"dlopen's parameter zu seindlopen(pFilepath, RTLD_LAZY | RTLD_LOCAL).

Aber wenn wir die Engine neu geschrieben haben, um sie in gemeinsam genutzte Bibliotheken aufzuteilen (für den eventuellen Zweck der Wiederverwendung in den Plugins), erhalten wir den Segfault-Fehler erneut. Und wenn man sich den Stack-Trace ansieht, geht es von der Engine -> Plugin -> Engine.

Gibt es eine Möglichkeit, für den Laufzeit-Linker festzulegen, dass Symbole des Plugins nicht der Engine zugeordnet werden (insbesondere, wenn sie im Plugin definiert sind)?

Vielen Dank! Matt

Bearbeitet am 03.12.2009

Ich habe zuerst versucht, den Code des Plugins in einen eigenen Namespace zu packen. Das hat nicht funktioniert, da es statisch mit einer Bibliothek verknüpft ist, die auch mit der Engine verknüpft ist. Die Versionen der statischen Bibliothek sind unterschiedlich, also segfault!

Dann habe ich den Build der Engine geändert und die Bibliotheken statisch verknüpft. Und wenn ich es starte, habe ich das Problem nicht mehr. Es scheint also, dass die Symbole der gemeinsam genutzten Bibliothek exportiert und dann beim Öffnen dynamisch in das Plugin verschoben wurden. Wenn sich der gesamte Code der Engine in einer einzigen ausführbaren Datei befindet, werden die Symbole nicht exportiert (daher wird nicht versucht, die Symbole des Plugins in die Engine zu verschieben).

Ich habe jedoch immer noch ein Problem, da es eine parallelisierte Version des Programms gibt (mit Open-MPI), die immer noch den Segfault erhält. Es scheint, dass es immer noch die Symbole der Engine exportiert und das Plugin verschiebt. Dies hängt möglicherweise damit zusammen, wie Open-MPI die Anwendung ausführt.

Gibt es Linker-Flags, die für die gemeinsam genutzte Plugin-Bibliothek verwendet werden könnten, die darauf hinweisen, dass die Symbole zur Laufzeit nicht dynamisch verschoben werden sollen? Oder um die Symbole zu verbergen, damit sie nicht verlegt werden? ich habe es versucht-s ("Alle Symbolinformationen weglassen"), aber das hat anscheinend nichts an den dynamischen Symbolen geändert (überprüft mitnm -D <plugin>).