Wie kann die ABI-Kompatibilität für eine C++-Bibliothek gewährleistet werden, die mithilfe von Conan Drittanbietertypen C++

Programme in C++. Entwicklerforum
Anonymous
 Wie kann die ABI-Kompatibilität für eine C++-Bibliothek gewährleistet werden, die mithilfe von Conan Drittanbietertypen

Post by Anonymous »

Ich entwickle eine C++-Bibliothek (

Code: Select all

MyLib
), die auf Bibliotheken von Drittanbietern (insbesondere fmt) basiert. Meine Bibliothek besteht aus öffentlichen Headern und vorkompilierten Binärdateien.
Die Einschränkung:
Ich muss MyLib intern nur als vorkompilierte Binärdatei an andere Teams verteilen.
  • Die Verbraucher können MyLib nicht aus dem Quellcode neu kompilieren.
  • Wenn keine vorgefertigte Binärdatei vorhanden ist, die ihrer Konfiguration entspricht, muss der Prozess fehlschlagen, anstatt zu versuchen, sie zu erstellen.
Architektur:
  • Code: Select all

    MyLib
    macht Bibliotheken von Drittanbietern verfügbar, z

    Code: Select all

    fmt
    gibt seine öffentliche API (Header) ein.
  • Code: Select all

    MyLib
    wird mithilfe einer bestimmten Version von fmt (z. B. v9.1.0) und bestimmten Compiler-Flags in eine statische/gemeinsam genutzte Bibliothek kompiliert.
  • Die Consumer-App verknüpft MyLib über Conan. Conan ruft MyLib (binär) und fmt (Quelle zum Erstellen, falls nicht verfügbar oder binär) ab.
Die Angst:
Selbst wenn ich erzwinge, dass der Verbraucher genau die gleiche Versionsnummer von fmt (v9.1.0) verwendet, mache ich mir Sorgen über geringfügige Abweichungen in der Art und Weise, wie fmt darauf erstellt wird Seite. Wenn fmt mit leicht unterschiedlichen Optionen kompiliert wird, stimmt das Speicherlayout der Typen in meinen Headern nicht mit der Binärdatei überein, die ich vorkompiliert habe. Dies kann zu einer falschen Speicherzuordnung und stillen Fehlern führen.
**Beispielszenario:
MyLib.h (Öffentlicher Header)** Dieser Header ist sowohl in meinem Bibliotheksbuild als auch im Consumer enthalten.

Code: Select all

#pragma once
#include 

namespace mylib {
struct LogContext {
// The size/alignment of this member depends on how fmt was compiled.
fmt::memory_buffer buffer;
};

void process(LogContext& ctx);
}
MyLib Build Environment: Ich baue

Code: Select all

MyLib
[/b] (und Link gegen

Code: Select all

fmt
[/b] v9.1.0). Conan generiert ein

Code: Select all

package_id
[/b] für diese Binärdatei.
Verbraucherumgebung: Der Verbraucher fragt Conan nach

Code: Select all

MyLib
[/b]. Sie verwenden auch

Code: Select all

fmt
[/b] v9.1.0. Allerdings weist ihr Projekt möglicherweise eine leichte Abweichung auf oder muss fmt neu erstellt werden.
Wenn das Speicherlayout von

Code: Select all

fmt::memory_buffer
[/b] (oder jedes andere Objekt aus meinen Bibliotheken von Drittanbietern) ändert sich aufgrund bedingt kompilierter Mitglieder, meines vorkompilierten

Code: Select all

process()Die Funktion 
[/b] liest den Speichermüll, wenn sie dem des Verbrauchers übergeben wird

Code: Select all

LogContext
[/b].
Meine Fragen: Ist das oben Genannte eine berechtigte Sorge oder bin ich paranoid? Wie gehen andere mit einem solchen Szenario um, wenn es sich um ein berechtigtes Anliegen handelt?

Quick Reply

Change Text Case: 
   
  • Similar Topics
    Replies
    Views
    Last post