Kommentare¶

In Symboldateien werden Kommentare unterstützt. Jede Zeile, die mit ‚#’ als erstem Zeichen beginnt, ist ein Kommentar, falls sie nicht mit ‚#include’ beginnt (siehe Abschnitt "Includes verwenden"). Zeilen, die mit ‚#MISSING:’ anfangen, sind besondere Kommentare, die verschwundene Symbole dokumentieren.

Using metavariable substitutions¶

In some cases instead of hardcoding some variable text, we can use metavariables that will be replaced either when generating the symbols file shipped in the binary package, or during dependency generation.

Contrary to the #MINVER# metavariable, the following metavariables will never appear in a symbols file inside a binary package.

Using the #PACKAGE# metavariable

In some rare cases, the name of the library varies between architectures. To avoid hardcoding the name of the package in the symbols file, you can use the #PACKAGE# metavariable. It will be replaced by the real package name during installation of the symbols files.

Using the #CURVER# metavariable

In some cases, a symbol with an unstable ABI will require a strict dependency on the current package version. To avoid hardcoding the current version in the symbols file, you can use the #CURVER# metavariable. It will be replaced by a dependency version constraint in the form of “(= binary-version)”, where this would be generally be used in combination with #PACKAGE#.

Supported since dpkg 1.23.4.

Verwendung von Symbolkennzeichnungen¶

Symbolkennzeichnungen sind nützlich, um Symbole zu markieren, die in irgendeiner Weise besonders sind. Jedes Symbol kann eine beliebige Anzahl zugeordneter Kennzeichnungen besitzen. Während alle Kennzeichnungen ausgewertet und gespeichert werden, werden nur einige von dpkg-gensymbols verstanden und lösen eine Spezialbehandlung der Symbole aus. Lesen Sie den Unterabschnitt "Standardsymbolkennzeichnungen" für eine Referenz dieser Kennzeichnungen.

Kennzeichnungsspezifikationen kommen direkt vor dem Symbolnamen (dazwischen sind keine Leerraumzeichen erlaubt). Sie beginnen immer mit einer öffnenden Klammer (, enden mit einer schließenden Klammer ) und müssen mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden durch das Zeichen | getrennt. Jede der Kennzeichnungen kann optional einen Wert enthalten, der von der Kennzeichnung durch das Zeichen = getrennt wird. Kennzeichennamen und -werte können beliebige Zeichenketten sein, sie dürfen allerdings keine der der besonderen Zeichen ) | = enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, können optional mit den Zeichen ' oder " zitiert werden, um Leerraumzeichen darin zu erlauben. Falls keine Kennzeichnungen für das Symbol spezifiziert sind, werden Anführungszeichen als Teil des Symbolnamens behandelt, der bis zum ersten Leerzeichen geht.

  (Kennz1=bin markiert|Name mit Leerraum)"zitiertes gekennz Symbol"@Base 1.0
  (optional)gekennzeichnet_unzitiertes_Symbol@Base 1.0 1
  ungekennzeichnetes_Symbol@Base 1.0
Das erste Symbol im Beispiel heißt I<zitiertes gekennz Symbol> und hat zwei Kennzeichnungen: I<Kennz1> mit dem Wert I<bin markiert> und I<Name mit Leerraum> ohne Wert. Das zweite Symbol heißt I<gekennzeichnet_unzitiertes_Symbol> und ist nur mit dem Kennzeichen namens I<optional> gekennzeichnet. Das letzte Symbol ist ein Beispiel eines normalen, nicht gekennzeichneten Symbols.

Da Symbolkennzeichnungen eine Erweiterung des Formats deb-symbols(5) sind, können sie nur Teil der in Quellpaketen verwandten Symboldateien sein (diese Dateien sollten dann als Vorlagen zum Bau der Symboldateien, die in Binärpakete eingebettet werden, gesehen werden). Wenn dpkg-gensymbols ohne die Option -t aufgerufen wird, wird es alle Symbole ausgeben, die zum Format deb-symbols(5) kompatibel sind: Es verarbeitet die Symbole entsprechend der Anforderungen ihrer Standardkennzeichnungen und entfernt alle Kennzeichnungen aus der Ausgabe. Im Gegensatz dazu werden alle Symbole und ihre Kennzeichnungen (sowohl die Standardkennzeichnungen als auch die unbekannten) im Vorlagenmodus (-t) in der Ausgabe beibehalten und in ihrer Originalform, wie sie geladen wurden, auch geschrieben.

Standard-Symbolkennzeichnungen¶

optional

Ein als „optional“ gekennzeichnetes Symbol kann jederzeit von der Bibliothek verschwinden und wird nie zum Fehlschlag von dpkg-gensymbols führen. Verschwundene optionale Symbole werden kontinuierlich als MISSING (Fehlend) in dem Diff in jeder neuen Paketversion auftauchen. Dieses Verhalten dient als Erinnerung für den Betreuer, dass so ein Symbol aus der Symboldatei entfernt oder wieder der Bibliothek hinzugefügt werden muss. Wenn das optionale Symbol, das bisher als MISSING angegeben gewesen war, plötzlich in der nächsten Version wieder auftaucht, wird es wieder auf den Status „existing“ (existierend) gebracht, wobei die minimale Version unverändert bleibt.

Diese Markierung ist für private Symbole nützlich, deren Verschwinden keinen ABI-Bruch auslöst. Beispielsweise fallen die meisten C++-Template-Instanziierungen in diese Kategorie. Wie jede andere Markierung kann auch diese einen beliebigen Wert haben: sie könnte angeben, warum dieses Symbol als optional betrachtet wird.

arch=Architekturliste

arch-bits=Architektur-Bits

arch-endian=Architektur-Bytereihenfolge

These tags allow one to restrict the set of architectures where the symbol is supposed to exist. When the symbols list is updated with the symbols discovered in the library, all arch-specific symbols which do not concern the current host architecture are treated as if they did not exist. If an arch-specific symbol matching the current host architecture does not exist in the library, normal procedures for missing symbols apply and it may cause dpkg-gensymbols to fail. On the other hand, if the arch-specific symbol is found when it was not supposed to exist (because the current host architecture is not listed in the tag or does not match the endianness and bits), it is made arch neutral (i.e. the arch, arch-bits and arch-endian tags are dropped and the symbol will appear in the diff due to this change), but it is not considered as new.

Beim Betrieb im standardmäßigen nicht-Vorlagen-Modus werden unter den architekturspezifischen Symbolen nur die in die Symboldatei geschrieben, die auf die aktuelle Host-Architektur passen. Auf der anderen Seite werden beim Betrieb im Vorlagenmodus alle architekturspezifischen Symbole (darunter auch die von fremden Architekturen) immer in die Symboldatei geschrieben.

Das Format der Architekturliste ist das gleiche wie das des Feldes Build-Depends in debian/control (außer den einschließenden eckigen Klammern []). Beispielsweise wird das erste Symbol aus der folgenden Liste nur auf den Architekturen Arm64, Any-amd64 und Riscv64 betrachtet, das zweite nur auf Linux-Architekturen, während das dritte überall außer auf Armel betrachtet wird.

  (arch=arm64 any-amd64 riscv64)Arch_spezifisches_Symbol@Base 1.0
  (arch=linux-any)Linux_spezifisches_Symbol@Base 1.0
  (arch=!armel)Symbol_das_Armel_nicht_hat@Base 1.0
    

Architektur-Bits ist entweder 32 oder 64.

  (arch-bits=32)32_Bit_spezifisches_Symbol@Base 1.0
  (arch-bits=64)64_Bit_spezifisches_Symbol@Base 1.0
    

Architektur-Bytereihenfolge ist entweder little oder big.

  (arch-endian=little)Little_Endian_spezifisches_Symbol@Base 1.0
  (arch-endian=big)Big_Endian_spezifisches_Symbol@Base 1.0
    

Mehrere Einschränkungen können aneinandergehängt werden.

  (arch-bits=32|arch-endian=little)32_Bit_Le_Symbol@Base 1.0
    

Support for tags arch-bits and arch-endian since dpkg 1.18.0.

allow-internal

dpkg-gensymbols has a list of internal symbols that should not appear in symbols files as they are usually only side-effects of implementation details of the toolchain. If for some reason, you really want one of those symbols to be included in the symbols file, you should tag the symbol with allow-internal. It can be necessary for some low level toolchain libraries like “libgcc”.

Unterstützt seit Dpkg 1.20.1.

c++

Gibt c++-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt "Verwendung von Symbolmustern".

symver

Gibt symver (Symbolversion)-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt "Verwendung von Symbolmustern".

regex

Gibt regex-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt "Verwendung von Symbolmustern".

Verwendung von Symbolmustern¶

Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale Symbole aus der Bibliothek abdecken. dpkg-gensymbols wird versuchen, jedes Muster auf jedes reale Symbol, für das kein spezifisches Symbolgegenstück in der Symboldatei definiert ist, abzugleichen. Wann immer das erste passende Muster gefunden wurde, werden alle Kennzeichnungen und Eigenschaften als Basisspezifikation des Symbols verwandt. Falls keines der Muster passt, wird das Symbol als neu betrachtet.

A pattern is considered lost if it does not match any symbol in the library. By default this will trigger a dpkg-gensymbols failure under -c1 or higher level. However, if the failure is undesired, the pattern may be marked with the optional tag. Then if the pattern does not match anything, it will only appear in the diff as MISSING. Moreover, like any symbol, the pattern may be limited to the specific architectures with the arch tag. See the "Standard symbol tags" subsection above for more information.

Patterns are an extension of the deb-symbols(5) format hence they are only valid in symbol file templates. Pattern specification syntax is not any different from the one of a specific symbol. However, symbol name part of the specification serves as an expression to be matched against name@version of the real symbol. To distinguish among different pattern types, a pattern will typically be tagged with a special tag.

Derzeit unterstützt dpkg-gensymbols drei grundlegene Mustertypen:

c++

Dieses Muster wird durch die Kennzeichnung c++ verzeichnet. Es passt nur auf die entworrenen („demangled“) Symbolnamen (wie sie vom Hilfswerkzeug c++filt(1) ausgegeben werden). Dieses Muster ist sehr hilfreich, um auf Symbole zu passen, bei dem die verworrenen („mangled“) Namen sich auf verschiedenen Architekturen unterscheiden während die entworrenen die gleichen bleiben. Eine Gruppe solcher Symbole ist non-virtual thunks, die einen architekturspezifischen Versatz in ihren verworrenen Namen eingebettet haben. Eine häufige Instanz dieses Falles ist ein virtueller Destruktor, der unter rautenförmiger Vererbung ein nicht-virtuelles Thunk-Symbol benötigt. Selbst wenn beispielsweise _ZThn8_N3NSB6ClassDD1Ev@Base auf 32 Bit-Architekturen _ZThn16_N3NSB6ClassDD1Ev@Base auf 64 Bit-Architekturen ist, kann es mit einem einzigen c++-Muster abgeglichen werden:

 libdummy.so.1 libdummy1 #MINVER#
  […]
  (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
  […]
    

Der entworrene Name oben kann durch Ausführung folgenden Befehls erhalten werden:

  $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
    

Note that while mangled name is unique in the library by definition, this is not necessarily true for demangled names. A couple of distinct real symbols may have the same demangled name. For example, that's the case with non-virtual thunk symbols in complex inheritance configurations or with most constructors and destructors (since g++ typically generates two real symbols for them). However, as these collisions happen on the ABI level, they should not degrade quality of the symbol file.

symver

Dieses Muster wird durch die Kennzeichnung symver verzeichnet. Gut betreute Bibliotheken verfügen über versionierte Symbole, wobei jede Version zu der Version der Originalautoren passt, in der dieses Symbol hinzugefügt wurde. Falls das der Fall ist, können Sie ein symver-Muster verwenden, das auf jedes zu einer spezifizierten Version zugehörige Symbol passt. Beispiel:

 libc.so.6 libc6 #MINVER#
  (symver)GLIBC_2.0 2.0
  […]
  (symver)GLIBC_2.7 2.7
  access@GLIBC_2.0 2.2
    

Alle den Versionen GLIBC_2.0 und GLIBC_2.7 zugeordneten Symbole werden zu einer minimalen Version 2.0 bzw. 2.7 führen, wobei das Symbol access@GLIBC_2.0 die Ausnahme darstellt. Es wird zu einer minimalen Abhängigkeit auf libc6 Version 2.2 führen, obwohl es im Geltungsbereich des Musters „(symver)GLIBC_2.0“ gehört, da spezielle Symbole vor Mustern Vorrang haben.

Note that while old style wildcard patterns (denoted by "*@version" in the symbol name field) are still supported, they have been deprecated by new style syntax "(symver|optional)version". For example, "*@GLIBC_2.0 2.0" should be written as "(symver|optional)GLIBC_2.0 2.0" if the same behavior is needed.

regex

Muster mit regulären Ausdrücken werden durch die Kennzeichnung regex verzeichnet. Sie passen auf den regulären Ausdruck von Perl, der im Symbolnamenfeld angegeben ist. Ein regulärer Ausdruck wird wie er ist abgeglichen. Denken Sie daher daran, ihn mit dem Zeichen ^ zu beginnen, da er ansonsten auf jeden Teil der Zeichenkette des realen Symbols name@version passt. Beispiel:

 libdummy.so.1 libdummy1 #MINVER#
  (regex)"^mystack_.*@Base$" 1.0
  (regex|optional)"private" 1.0
    

Symbole wie „mystack_new@Base“, „mystack_push@Base“, „mystack_pop@Base“ usw. passen auf das erste Muster, während dies für „ng_mystack_new@Base“ nicht der Fall ist. Das zweite Muster wird auf alle Symbole, die die Zeichenkette „private“ in ihren Namen enthalten, passen und die abgeglichenen Symbole erben die Kennzeichnung optional vom Muster.

Die oben aufgeführten grundlegenden Muster können - wo es Sinn ergibt - kombiniert werden. In diesem Fall werden sie in der Reihenfolge verarbeitet, in der die Kennzeichnungen angegeben sind. Im Beispiel

  (c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
  (regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0

werden die Symbole „_ZN3NSA6ClassA7Private11privmethod1Ei@Base“ und „_ZN3NSA6ClassA7Private11privmethod2Ei@Base“ verglichen. Beim Vergleichen des ersten Musters wird das rohe Symbol erst als C++-Symbol entworren, dann wird der entworrene Name mit den regulären Ausdruck verglichen. Auf der anderen Seite wird beim Vergleichen des zweiten Musters der reguläre Ausdruck gegen den rohen Symbolnamen verglichen, dann wird das Symbol überprüft, ob es ein C++-Symbol ist, indem das Entwirren versucht wird. Ein Fehlschlag eines einfachen Musters wird zum Fehlschlag des gesamten Musters führen. Daher wird beispielsweise „__N3NSA6ClassA7Private11privmethod\dEi@Base“ auf keines der Muster passen, da es kein gültiges C++-Symbol ist.

Im Allgemeinen werden die Muster in zwei Kategorien eingeteilt: Aliase (grundlegende c++- und symver-Muster) und generische Muster (regex und alle Kombinationen grundlegender Muster). Abgleichen von grundlegenden alias-basierenden Mustern ist schnell (O(1)), während generische Muster O(N) (wobei N die Anzahl der generischen Muster ist) für jedes Symbol ist. Daher wird empfohlen, generische Muster nicht zu viel zu verwenden.

When multiple patterns match the same real symbol, aliases (first c++, then symver) are preferred over generic patterns. Generic patterns are matched in the order they are found in the symbol file template until the first success. Note, however, that manual reordering of template file entries is not recommended because dpkg-gensymbols generates diffs based on the alphanumerical order of their names.

Includes verwenden¶

Wenn der Satz der exportierten Symbole sich zwischen Architekturen unterscheidet, kann es ineffizient werden, eine einzige Symboldatei zu verwenden. In diesen Fällen kann sich eine Include-Direktive in einer Reihe von Arten als nützlich erweisen:

• Sie können den gemeinsamen Teil in eine externe Datei auslagern und diese Datei dann in Ihre Paket.symbols.Arch-Datei mit einer include-Direktive wie folgt einbinden:

   #include "I<Pakete>.symbols.common"
      

• Die Include-Direktive kann auch wie jedes Symbol gekennzeichnet werden:

   (Kennzeichen|…|KennzeichenN)#include "einzubindende-Datei"
      

  Als Ergebnis werden alle Symbole aus der einzubindende-Datei standardmäßig als mit Kennzeichen … KennzeichenN gekennzeichnet betrachtet. Sie können diese Funktionalität benutzen, um eine gemeinsame Datei Paket.symbols zu erstellen, die architekturspezifische Symboldateien einbindet:

    gemeinsames_Symbol1@Base 1.0
   (arch-bits=64)#include "Paket.symbols.64-bit"
   (arch-bits=32)#include "Paket.symbols.32-bit"
    gemeinsames_Symbol2@Base 1.0
      

Die Symboldateien werden Zeile für Zeile gelesen und include-Direktiven werden bearbeitet, sobald sie erkannt werden. Das bedeutet, dass der Inhalt der mit include eingebundenen Datei jeden Inhalt überschreiben kann, der vor der Include-Direktive aufgetaucht ist und Inhalt nach der Direktive alles aus der eingebundenen Datei überschreiben kann. Jedes Symbol (oder sogar weitere #include-Direktiven) in der eingebundenen Datei kann zusätzliche Kennzeichnungen spezifizieren oder Werte der vererbten Kennzeichnungen in ihrer Kennzeichnungsspezifikation überschreiben. Allerdings gibt es keine Möglichkeit für ein Symbol, die ererbten Kennzeichnungen zu überschreiben.

Eine eingebundene Datei kann die Kopfzeile wiederholen, die den SONAME der Bibliothek enthält. In diesem Fall überschreibt sie jede vorher gelesene Kopfzeile. Allerdings ist es im Allgemeinen am besten, die Wiederholung von Kopfzeilen zu vermeiden. Eine Art, dies zu erreichen, ist wie folgt:

 #include "libirgendwas1.symbols.common"
  arch_spezifisches_Symbol@Base 1.0