Was ist zu tun, wenn zwei gemeinsam genutzte Bibliotheken von der gleichen Version eines Drittanbieters abhängen, die unterschiedlich kompiliert wurde?

Question

Meine Anwendung hängt von einer bestimmten Version von Xerces ab (kompiliert mit bestimmten Flags):

$ ldd actimize_intelligence_server | grep xerces
    libxerces-c.so.28 => ./libxerces-c.so.28 (0x00002b3c1518f000)

Eine gemeinsam genutzte Bibliothek (die von einem Client empfangen wurde) hängt ebenfalls von xerces ab (anscheinend mit anderen Flags kompiliert):

$ ldd libgqt.so | grep xerces
    libxerces-c.so.28 => ./bin/libxerces-c.so.28 (0x00002b1f3d28f000)

Beim Versuch, die Anwendung zu starten, wird dieser Fehler angezeigt:

symbol lookup error: libgqt.so: undefined symbol: _ZN11xercesc_2_825DOMImplementationRegistry20getDOMImplementationEPKt

Das fehlende Symbol ist dieses:

xercesc_2_8::DOMImplementationRegistry::getDOMImplementation(unsigned short const*)

Während das exportierte Symbol aus meiner libxerces-c.so.28 dies ist:

xercesc_2_8::DOMImplementationRegistry::getDOMImplementation(wchar_t const*)

Ich vermute also, dass das das Problem ist. Das Ausführen von strace beim Starten der Anwendung zeigte, dass mein libxerces-c.so.28 geladen wird:

open("/home/test/app/libxerces-c.so.28", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\365\31\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0555, st_size=5757256, ...}) = 0
mmap(NULL, 6791128, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ba744950000
mprotect(0x2ba744e82000, 1044480, PROT_NONE) = 0
mmap(0x2ba744f81000, 299008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x531000) = 0x2ba744f81000
close(3)

Ohne weitere Vorkommnisse von libxerces-c.so.28 .

Und hier endet mein kleines Wissen über Linux.

Kann ich die anderen irgendwie dazu zwingen libxerces-c.so.28 zu laden, obwohl sie bereits geladen ist?
Wenn nicht, habe ich andere Möglichkeiten, als meinem Kunden zu sagen, dass er seinen Code neu kompilieren muss, damit er mit unserem Xerces funktioniert?

Answer 1

Das können Sie gar nicht tun. Bringen Sie die Binärkompatibilität nicht durcheinander - wenn Sie dynamisch auf dieselbe Bibliothek linken wollen, muss sie identisch kompiliert werden.

Answer 2

Sie haben nicht gesagt, was Sie brauchen libgqt.so und wie sehr Ihre Bewerbung davon abhängt.

Wenn Sie sind nicht wirklich abhängig von libgqt.so und nur eine Handvoll Symbole daraus verwenden, um etwas für diesen speziellen Kunden zu tun, dann dlmopen(LM_ID_NEWLM, "libgqt.so", RTLD_NOW) kann eine praktikable Lösung sein. Dokumentation aquí .

Im Allgemeinen hat DeadMG recht: Es ist am besten, wenn Sie sicherstellen, dass Sie genau dieselbe Kompilierung von xerces verwenden, sonst wird es Ihnen früher oder später wehtun.

Beachten Sie, dass das statische Einbinden von xerces in Ihre Anwendung höchstwahrscheinlich nicht praktikabel ist. Alles wird scheinbar funktionieren, nur um später zu unvorhersehbaren Zeiten abzustürzen.