Konflikte zwischen statischen und gemeinsam genutzten Bibliothekssymbolen?

Question

Ich arbeite an einem Projekt, das FreeImage und openCV verwendet. Derzeit nutzen wir die jpeg-Unterstützung von beiden (ich arbeite daran, das zu beheben, aber im Moment muss es so bleiben). Wie auch immer, FreeImage kompiliert libjpeg 7.0 in seine statischen Bibliotheken, und openCV's highgui Bibliothek bindet es als Shared Library ein (auf meinem System, Ubuntu 9, habe ich libjpeg 6.2 installiert).

Sie werden in eine endgültige Bibliothek verlinkt, die zur Verknüpfung mit verschiedenen Programmen, Java-Wrappern usw. verwendet wird. All das funktioniert einwandfrei, ohne Symbolkonflikte oder ähnliches während der Kompilier-/Linkzeit. Wenn ich jedoch ein Bild mit der Funktion openCV cvLoadImage öffnen möchte, bricht es beim Lesen des Headers ab, was höchstwahrscheinlich auf die Unterschiede zwischen Headern in 6.2 und 7.0 zurückzuführen ist.

Wenn ich die Verknüpfung von FreeImage aufhebe (und den Code, der es benötigt, auskommentiere), funktionieren die openCV-Aufrufe wieder, so dass die statischen libjpeg-Symbole von FreeImage eindeutig in Konflikt mit den Symbolen stehen, die aus der gemeinsam genutzten libjpeg-Bibliothek geladen werden würden. Was ich nicht herausfinden kann, ist, warum mein Compiler nicht einen Fehler während des Linkens wegen der zwei Sätze von libjpeg-Symbolen auslöst. Darüber hinaus habe ich versucht, mein System jpeglib.h Header mit der 7.0-Version vorübergehend zu ersetzen, um zu sehen, ob openCV kompiliert mit, dass würde dann synchronisieren mit den Symbolen, die freeimage an den Tisch bringt, ohne Erfolg scheint es.

Zuletzt habe ich ein printf in jpeg_read_header in der libjpeg, die freeimage kompiliert, eingefügt und neu erstellt, um zu sehen, ob openCV die freeimage libjpeg Definition verwendet. Es wurde nicht ausgedruckt, also muss ich annehmen, dass dies nicht der Fall ist.

Meine Fragen lauten also

1) Warum erzeugt das Verknüpfen einer statischen libjpeg und einer gemeinsam genutzten libjpeg keine Verknüpfungsfehler aufgrund von doppelten Symbolen?

2) Weiß jemand, warum diese beiden Dinge im Widerspruch zueinander stehen?

Edit: Das Kompilieren von openCV im Debug-Modus und dann wieder im normalen Modus scheint etwas gelöst zu haben und es funktioniert wieder, keine Ahnung was los ist.

Answer 1

Im Allgemeinen ist der Linker damit einverstanden, dass mehrere Bibliotheken übergeben werden, die alle dasselbe Symbol bzw. dieselben Symbole auflösen. Er verwendet einfach die erste, die er findet. Die Reihenfolge der Bibliotheken auf Ihrer Linker-Befehlszeile bestimmt, welche Bibliothek "gewinnt".

Dies gilt übrigens NICHT für Objektdateien. Jeder Linker, den ich je benutzt habe, geht davon aus, dass Sie wollen alle von Ihnen angegebenen Objekte zu verwenden, und beschwert sich, wenn mehr als eines das gleiche Symbol hat.

Answer 2

Sie müssen die Verknüpfungsoptionen so ändern, dass nur die gewünschten Symbole exportiert werden, dann werden alle konfliktbehafteten Symbole intern in der statischen Verknüpfung ausgeblendet, und es gibt keine Konflikte. Standardmäßig werden alle Symbole exportiert, das ist das Problem. Siehe diesen Link: http://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html

Answer 3

Es ist wie folgt

Statische Bibliotheken werden einkompiliert, dynamische Bibliotheken werden während der Laufzeit geladen, aber nur die Symbole, die fehlen (ich denke). Sie können freigegebene Bibliotheken einkompilieren, und dann erhalten Sie wahrscheinlich Symbol Kollision.

so opencv verwendet Symbole, die in kompiliert werden, da sie bereits vorhanden sind, anstatt die aus dynamischen Bibliotheken. Sie am Ende mit statischen Symbolen, möglicherweise mit unterschiedlichen Signaturen, aus Perspektive der opencv.