Betrachten Sie Folgendes:
Ich habe X mit der strikten Anforderung entwickelt, Y v2.0 für einige interne Geschäfte zu verwenden. Das heißt, ich kann auf keinen Fall zu Y v1.0 zurückkehren.
Auf der anderen Seite hat der Entwickler ähnliche Einschränkungen, um Y v1.0 zu verwenden.
Wie Sie bereits argumentieren können, lautet die Frage: Wie kann ich Y in X verknüpfen, ohne Y-Symbole zu exportieren, um Kollisionen zu vermeiden? Y ist gut etabliert, und möglicherweise möchte ich nicht seinen Quellcode ändern oder Einstellungen erstellen (wenn öffentlich verfügbar).
Um etwas mehr auf die Erde zu bringen, bin ich gerade dabei, ein SDK zu entwickeln, das sicher Bibliotheken von Drittanbietern benötigt, sagen wir zlib.
In meiner Entwicklung werde ich mich auf zlib v1.2.3.4.5.rc6 verlassen, weil ich es ausgiebig und erfolgreich benutzt und getestet habe, und ich kann mir das SDK-Testen / Fixieren nicht leisten, wenn ich die Version ändere.
Alle statisch oder dynamisch verknüpften Bibliotheken, die das SDK anbietet, müssen die statischen 3rd Party Libraries verstecken.
Der potentielle Kunde könnte ähnlichen Einschränkungen unterliegen (er benötigt zlib v7.8.9), also wie kann ich Symbolkollisionen vermeiden? Auch hier möglicherweise ohne Änderung des ursprünglichen Quellcodes (Namespace etc.).
Um die Dinge zu komplizieren, ist das SDK plattformübergreifend, was bedeutet, dass ich je nach Plattform (Windows, Linux, Mac OS, iOS, Android, ...) und dem verwendeten Compiler (zB MSVC ++) verschiedene Wege zur Lösung des Problems brauchen würde und g ++).
Danke.
Aktualisieren
Es scheint, ich bin VENDOR2 dieser Frage:
Verknüpfen mit mehreren Versionen einer Bibliothek
Bstpierres Antwort scheint eine praktikable Lösung zu sein, aber ich bin mir nicht sicher, ob es funktioniert oder ob es auf anderen Betriebssystemen als * nix reproduziert werden kann.
Ich hatte dieses Problem viele Male mit statischen Bibliotheken, zuletzt mit MSVCRT. Mit einer einzigen ausführbaren Datei steht die Ein-Definition-Regel im Weg, wie ein Kommentator hervorhebt. Es gibt wirklich keinen Weg, an den ich denken kann, wenn ich keine Binärdateien patchen muss. Und Sie müssten dies "tief" tun - alle internen Referenzen, die die statische Bibliothek Y (zlib) erzeugt, in ihre eigenen externen Verknüpfungsobjekte auffassen.
In diesem Fall würde ich vorschlagen, eine dynamische Bibliothek (DLL oder SO) zu verwenden. Es wird ein wenig Aufwand für die Bereitstellung hinzufügen. Aber es stellt eine ausführbare "Firewall" zur Verfügung, die es ermöglicht, dass globale Objekte mit demselben Namen in jeder Binärdatei liegen, ohne zu kollidieren. Trotzdem kann es zu Problemen führen, wenn sowohl die App als auch die DLL widersprüchliche Abhängigkeiten von Drittanbietern aufweisen. Trotzdem, wahrscheinlich die beste Option.