abicompat – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

abicompat – ABI-Kompatibilität prüfen

abicompat prüft, ob eine Anwendung, die eine Verbindung zu einer bestimmten gemeinsam genutzten Bibliothek herstellt, noch aktiv ist
ABI ist mit einer Folgeversion dieser Bibliothek kompatibel. Wenn die neue Version des
Wenn die Bibliothek eine ABI-Inkompatibilität einführt, weist abicompat den Benutzer darauf hin, was genau
diese Inkompatibilität ist.

AUFRUF

abicompat [Optionen] [ ]

OPTIONAL

· --help

Zeigt eine kurze Hilfe zum Befehl und zum Beenden an.

· --Version | -v

Zeigen Sie die Version des Programms an und beenden Sie es.

· --list-undefinierte-Symbole | -u

Zeigen Sie die Liste der nicht definierten Symbole der Anwendung an und beenden Sie sie.

· --show-base-names | -b

Im resultierenden, vom Tool ausgegebenen Bericht macht diese Option die Anwendung und
Auf Bibliotheken kann nur mit ihrem Basisnamen verwiesen werden. nicht mit einem vollständigen absoluten Namen. Das
kann für die Verwendung in Skripten nützlich sein, die Namen der Anwendung und vergleichen möchten
Bibliotheken unabhängig von ihrem Verzeichnisnamen.

· --app-debug-info-dir

Legen Sie den Pfad zu dem Verzeichnis fest, in dem sich die Debug-Informationen der Anwendung befinden
soll angelegt werden. Dies ist nützlich für Anwendungsbinärdateien, für die das Debuggen erforderlich ist
Informationen befinden sich in einem separaten Satz von Dateien.

· --lib-debug-info-dir1

Legen Sie den Pfad zu dem Verzeichnis fest, in dem sich die Debug-Informationen der ersten Version befinden
der Shared Library angelegt werden soll. Dies ist nützlich für gemeinsam genutzte Bibliotheken
Binärdateien, für die sich die Debug-Informationen in einem separaten Satz von Dateien befinden.

· --lib-debug-info-dir2

Legen Sie den Pfad zu dem Verzeichnis fest, in dem sich die Debug-Informationen der zweiten Version befinden
der Shared Library angelegt werden soll. Dies ist nützlich für gemeinsam genutzte Bibliotheken
Binärdateien, für die sich die Debug-Informationen in einem separaten Satz von Dateien befinden.

· --no-show-locs
Zeigen Sie keine Informationen darüber an, wo in der zweite von Locals geführtes Bibliothek die jeweiligen
Typ wurde geändert.

· --weak-mode

Dies löst den schwachen Modus aus Abikompat. In diesem Modus ist nur eine Version des
Bibliothek ist erforderlich. Das heißt, abicompat wird wie folgt aufgerufen:

abicompat --weak-mode

Beachten Sie, dass die --weak-mode Option kann sogar weggelassen werden, wenn nur eine Version der
Die Bibliothek wird zusammen mit der Anwendung bereitgestellt. In diesem Fall, Abikompat Im Prinzip so, wie Sie es von Google Maps kennen.
Schalter für den Betrieb im schwachen Modus:

abicompat

In diesem schwachen Modus sind die von der Bibliothek exportierten Funktions- und Variablentypen und
von der Anwendung verbraucht (wie in den Symbolen dieser Funktionen und Variablen).
sind in der Anwendung undefiniert und werden von der Bibliothek definiert und exportiert).
im Vergleich zu der von der Anwendung erwarteten Version dieser Typen. Und wenn diese
zwei Versionen von Typen sind unterschiedlich, Abikompat teilt dem Benutzer die Unterschiede mit
sind.

Mit anderen Worten, in diesem Modus Abikompat prüft, ob die Typen der Funktionen und
Von der Bibliothek exportierte Variablen bedeuten dasselbe wie die Anwendung
erwartet, was das ABI betrifft.

Beachten Sie, dass in diesem Modus Abikompat erkennt exportierte Funktionen oder Variablen nicht
(Symbole), die von der Anwendung erwartet werden, aber aus der Bibliothek entfernt werden.
Deshalb heißt es schwach Modus arbeiten können.

RÜCKKEHR WERTE

Der Exit-Code des Abikompat Der Befehl ist entweder 0, wenn der ABI der Binärdateien ist
Die verglichenen Werte sind gleich oder ungleich Null, wenn sie unterschiedlich sind oder das Tool einen Fehler festgestellt hat.

Im letzteren Fall ist der Exit-Code ein 8 Bit breites Bitfeld, in dem jedes Bit einen hat
spezifische Bedeutung.

Das erste Bit mit dem Wert 1, benannt ABIDIFF_ERROR bedeutet, dass ein Fehler aufgetreten ist.

Das zweite Bit mit dem Wert 2, benannt ABIDIFF_USAGE_ERROR bedeutet, dass ein Fehler aufgetreten ist
Der Benutzer hat das Tool aufgerufen. Es kann beispielsweise festgelegt werden, wenn der Benutzer das Tool aufgerufen hat
mit einem unbekannten Befehlszeilenschalter, mit einer falschen Zahl oder einem falschen Argument usw. Wenn dieses Bit vorhanden ist
eingestellt, dann die ABIDIFF_ERROR Das Bit muss ebenfalls gesetzt sein.

Das dritte Bit mit dem Wert 4, benannt ABIDIFF_ABI_CHANGE bedeutet den ABI der Binärdateien
verglichen sind unterschiedlich.

Das vierte Bit mit dem Wert 8 wird benannt ABIDIFF_ABI_INCOMPATIBLE_CHANGE bedeutet den ABI des
Die verglichenen Binärdateien unterscheiden sich auf inkompatible Weise. Wenn dieses Bit gesetzt ist, dann wird die
ABIDIFF_ABI_CHANGE Das Bit muss ebenfalls gesetzt sein. Wenn die ABIDIFF_ABI_CHANGE eingestellt ist und die
ABIDIFF_INCOMPATIBLE_CHANGE is NICHT gesetzt, dann bedeutet das, dass die ABIs verglichen werden könnten
oder möglicherweise nicht kompatibel. In diesem Fall muss ein Mensch die ABI-Änderungen überprüfen
um zu entscheiden, ob sie kompatibel sind oder nicht.

Die restlichen Bits werden im Moment nicht verwendet.

ANWENDUNG Beispiele:

· Erkennen einer möglichen ABI-Inkompatibilität in einer neuen gemeinsam genutzten Bibliotheksversion:

$ cat -n test0.h
1 Struktur foo
fünfzehn {
3 int m0;
4
5 Fuß()
6: m0()
7 {}
8 };
9
10 Fuß*
11 first_func();
12
13 nichtig
14 second_func(foo&);
15
16 nichtig
17 Third_func();
$

$ cat -n test-app.cc
1 // Kompilieren mit:
2 // g++ -g -Wall -o test-app -L. -ltest-0 test-app.cc
3
4 #include „test0.h“
5
6 int
7 main()
fünfzehn {
9 foo* f = first_func();
10 second_func(*f);
11 gibt 0 zurück;
12}
$

$ cat -n test0.cc
1 // Kompilieren Sie dies mit:
2 // g++ -g -Wall -shared -o libtest-0.so test0.cc
3
4 #include „test0.h“
5
6 Fuß*
7 first_func()
fünfzehn {
9 foo* f = new foo();
10 Rückkehr f;
11}
12
13 nichtig
14 second_func(foo&)
fünfzehn {
16}
17
18 nichtig
19 Third_func()
fünfzehn {
21}
$

$ cat -n test1.h
1 Struktur foo
fünfzehn {
3 int m0;
4 Zeichen m1; /* <-- hier wurde ein neues Mitglied hinzugefügt! */
5
6 Fuß()
7 : m0(),
8 m1()
9 {}
10 };
11
12 Fuß*
13 first_func();
14
15 nichtig
16 second_func(foo&);
17
18 nichtig
19 Third_func();
$

$ cat -n test1.cc
1 // Kompilieren Sie dies mit:
2 // g++ -g -Wall -shared -o libtest-1.so test1.cc
3
4 #include „test1.h“
5
6 Fuß*
7 first_func()
fünfzehn {
9 foo* f = new foo();
10 Rückkehr f;
11}
12
13 nichtig
14 second_func(foo&)
fünfzehn {
16}
17
18 /* Kommentieren wir die Definition von Third_func() aus
19 nichtig
20 Third_func()
fünfzehn {
22}
23 */
$

· Kompilieren Sie die erste und zweite Version der Bibliotheken: libtest-0.so und
libtest-1.so:

$ g++ -g -Wall -shared -o libtest-0.so test0.cc
$ g++ -g -Wall -shared -o libtest-1.so test1.cc

· Kompilieren Sie die Anwendung und verknüpfen Sie sie mit der ersten Version der Bibliothek.
Außergewöhnliches Test-App binär:

$ g++ -g -Wall -o test-app -L. -ltest-0.so test-app.cc

· Jetzt benutzen Abikompat um zu sehen, ob libtest-1.so ABI-kompatibel mit der App ist
zum ABI von libtest-0.so:

$ abicompat test-app libtest-0.so libtest-1.so
Die ELF-Datei „test-app“ ist aufgrund der folgenden Unterschiede zu „libtest-1.so“ möglicherweise nicht ABI-kompatibel mit „libtest-0.so“:
Zusammenfassung der Funktionsänderungen: 0 entfernt, 2 geändert, 0 hinzugefügte Funktionen
Zusammenfassung der Variablenänderungen: 0 entfernt, 0 geändert, 0 Variable hinzugefügt

2 Funktionen mit einigen indirekten Untertypänderungen:

[C]'function foo* first_func()' hat einige indirekte Untertypänderungen:
Rückgabetyp geändert:
in wies auf den Typ „struct foo“ hin:
Größe von 32 auf 64 Bit geändert
1 Datenelement-Einfügung:
'char foo::m1', bei Offset 32 ​​(in Bits)
[C]'function void second_func(foo&)' hat einige indirekte Untertypänderungen:
Parameter 0 vom Typ „foo&“ weist Untertypänderungen auf:
Der referenzierte Typ „struct foo“ wurde geändert, wie bereits berichtet

$

· Verwenden Sie jetzt den schwachen Modus von abicompat, d. h. stellen Sie nur die Anwendung und die bereit
neue Version der Bibliothek:

$ abicompat --weak-mode test-app libtest-1.so
In der Bibliothek definierte Funktionen
'libtest-1.so'
haben Untertypen, die sich von der Anwendung unterscheiden
'Test-App'
erwartet:

Funktion foo* first_func():
Rückgabetyp geändert:
in wies auf den Typ „struct foo“ hin:
Größe von 32 auf 64 Bit geändert
1 Datenelement-Einfügung:
'char foo::m1', bei Offset 32 ​​(in Bits)

$

Nutzen Sie abicompat online über die Dienste von onworks.net