Zur Wiederholung: Ich suche nach ABI-Kompatibilität zwischen Bibliotheken der selben Visual-C ++ Version!
Wir wollen einige interne C ++ - DLLs verschiedener Teams mischen und abgleichen - zu unterschiedlichen Zeiten mit verschiedenen Projektdateien erstellt. Wegen der langen Build-Zeiten wollen wir große monolithische Builds vermeiden, bei denen jedes Team den Quellcode einer anderen Team-Bibliothek neu kompiliert.
Wenn C ++ DLLs mit C ++ - Schnittstellen konsumiert werden, ist eher clear das können Sie dies nur tun, wenn alle DLLs mit dem gleichen Compiler kompiliert werden / Visual Studio-Version.
Was mir nicht sofort klar ist, ist was , es muss genau dasselbe sein, um ABI-Kompatibilität zu erhalten.
_DEBUG ) und release ( NDEBUG ) können nicht gemischt werden - das wird aber auch daran deutlich, dass diese auf verschiedene Versionen der shared runtime verlinken. /O Schalter notwendig - beeinflusst der Optimierungsgrad die ABI Kompatibilität? (Ich bin mir ziemlich sicher nicht.) /EH switch verwenden? /volatile:ms|iso ...? Im Wesentlichen möchte ich eine Reihe von (Meta-) Daten erstellen, die mit einer Visual-C ++ - DLL verknüpft werden können, die die ABI-Kompatibilität beschreibt.
Wenn Unterschiede existieren, liegt mein Fokus momentan nur auf VS2015.
Habe in den letzten Tagen darüber nachgedacht, und was ich getan habe, war herauszufinden, ob einige Anwendungsfälle existieren, wo Entwickler bereits ihre C ++ - Builds kategorisieren mussten, um sicherzustellen, dass Binärdateien kompatibel sind.
Ein solcher Ort sind die nativen Pakete von nuget . Also habe ich mir dort ein Paket angeschaut, speziell die cpprestdk :
Die Binärdateien im herunterladbaren Paket so aufgeteilt:
%Vor%Ich habe das aus diesem Beispiel herausgezogen, weil ich keine anderen Dokumente finden konnte. Ich weiß auch, dass die Boost-Binaries Build-Verzeichnis in ähnlicher Weise getrennt ist.
Um zu einer Liste von Metadaten zu gelangen, um die ABI-Kompatibilität zu identifizieren, kann ich vorläufig Folgendes auflisten:
vc140 sollte heutzutage genug sein - wenn man bedenkt, wie die CRT eingebunden ist, müssen alle möglichen Bugfixes zu den versionierten CRT-Komponenten sowieso ABI-kompatibel sein, so dass es keine Rolle spielt, in welcher Version eine vorkompilierte Bibliothek erstellt wurde. _ITERATOR_DEBUG_LEVEL ... wenn alle mit den Standardeinstellungen arbeiten, in Ordnung, wenn ein Projekt dies nicht tut, muss es so deklariert werden Zusätzlich meine beste Schätzung bezüglich der folgenden Punkte:
/O spielt keine Rolle - wir mischen und stimmen Binaries ständig mit verschiedenen Optimierungseinstellungen ab - speziell funktioniert dies sogar für Objektdateien innerhalb derselben Binärdatei /volatile - da dies eine Code-Gen-Sache ist, kann ich mir schwer vorstellen, wie dies einen ABI brechen könnte
/EH - mit Ausnahme der Option, alle Ausnahmen zu deaktivieren, in welchem Fall Sie natürlich nichts nennen können, das wirft, bin ich ziemlich sicher, dass dies aus einer ABI-Perspektive sicher ist: Es gibt mögliche Fallstricke hier, aber ich denke, sie können nicht wirklich in ABI compat kategorisiert werden. (Vielleicht könnte man sagen, dass einige komplexe Callback-Ketten ABI-inkompatibel sind, nicht sicher) Andere:
/G.. ): I denke dies würde zum Zeitpunkt der Verknüpfung abbrechen, wenn verstümmelte Exportsymbole und Header-Deklarationen nicht übereinstimmen. /Zc:wchar_t - bricht zur Verbindungszeit ab (Es ist tatsächlich ABI-kompatibel, aber die Symbole werden nicht macth.) /GR ) - bin mir nicht sicher - ich habe nie mit diesem deaktiviert gearbeitet. Tags und Links visual-c++ visual-studio-2015 abi visual-c++-2015