637 lines
34 KiB
HTML
637 lines
34 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of dpkg-gensymbols</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>dpkg-gensymbols</H1>
|
|
Section: dpkg-Programmsammlung (1)<BR>Updated: 2020-03-23<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>BEZEICHNUNG</H2>
|
|
|
|
dpkg-gensymbols - erstelle Symboldateien (Abhängigkeitsinformationen für
|
|
Laufzeitbibliotheken)
|
|
<A NAME="lbAC"> </A>
|
|
<H2>ÜBERSICHT</H2>
|
|
|
|
<B>dpkg-gensymbols</B> [<I>Option</I> …]
|
|
<A NAME="lbAD"> </A>
|
|
<H2>BESCHREIBUNG</H2>
|
|
|
|
<B>dpkg-gensymbols</B> durchsucht einen temporären Baubaum (standardmäßig
|
|
debian/tmp), sucht nach Bibliotheken und erstellt eine Datei <I>symbols</I>, die
|
|
diese beschreibt. Diese Datei wird, falls sie nicht leer ist, in das
|
|
Unterverzeichnis DEBIAN des Baubaums installiert, so dass sie schlussendlich
|
|
in der Steuerinformation des Pakets auftaucht.
|
|
<P>
|
|
|
|
Beim Erstellen dieser Dateien verwendet es als Eingabe einige vom Betreuer
|
|
bereitgestellte Symboldateien. Es sucht nach den folgenden Dateien (und
|
|
verwendet die erste, die gefunden wird):
|
|
<DL COMPACT>
|
|
<DT id="1">•<DD>
|
|
debian/<I>Paket</I>.symbols.<I>Architektur</I>
|
|
<DT id="2">•<DD>
|
|
debian/symbols.<I>Architektur</I>
|
|
<DT id="3">•<DD>
|
|
debian/<I>Paket</I>.symbols
|
|
<DT id="4">•<DD>
|
|
debian/symbols
|
|
</DL>
|
|
<P>
|
|
|
|
Der Hauptzweck dieser Dateien besteht darin, die minimale Version
|
|
bereitzustellen, die mit jedem von der Bibliothek bereitgestellten Symbol
|
|
verknüpft ist. Normalerweise entspricht dies der ersten Version des Pakets,
|
|
die dieses Symbol bereitgestellt hat, kann aber vom Betreuer erhöht werden,
|
|
falls die ABI des Symbols ohne Brechen der Rückwärtskompatibilität erweitert
|
|
wurde. Es liegt in der Verwantwortung des Betreuers, diese Dateien aktuell
|
|
zu halten, aber <B>dpkg-gensymbols</B> hilft dabei.
|
|
<P>
|
|
|
|
Wenn die erstellten Symboldateien sich von denen, die der Betreuer
|
|
bereitgestellt hat, unterscheiden, wird <B>dpkg-gensymbols</B> ein Diff zwischen
|
|
den zwei Versionen anzeigen. Falls die Unterschiede desweiteren zu
|
|
gravierend sind, wird es sogar fehlschlagen (Sie können einstellen, wie
|
|
große Unterschiede Sie tolerieren können, sehen Sie hierzu die Option
|
|
<B>-c</B>).
|
|
<A NAME="lbAE"> </A>
|
|
<H2>SYMBOLDATEIEN PFLEGEN</H2>
|
|
|
|
Die Symboldateien sind nur wirklich nützlich, falls sie die Entwicklung
|
|
eines Paketes über mehrere Veröffentlichungen hinweg wiedergeben. Daher muss
|
|
der Betreuer sie immer aktualisieren, wenn eine neues Symbol hinzugefügt
|
|
wird, so dass die zugeordnete minimale Version der Realität entspricht. Die
|
|
in den Bauprotokollen enthaltenen Diffs können als Startpunkt benutzt
|
|
werden, aber zusätzlich hat der Betreuer sicherzustellen, dass sich das
|
|
Verhalten dieser Symbole nicht derart geändert hat, dass irgendetwas, was
|
|
diese Symbole verwendet und gegen die neue Version gelinkt ist, daran
|
|
hindern würde, mit der alten Version zu funktionieren. Meistens kann der
|
|
Diff direkt auf die Datei debian/<I>Paket</I>.symbols angewandt
|
|
werden. Allerdings werden normalerweise weitere Anpassungen notwendig: es
|
|
wird beispielsweise empfohlen, die Debian-Revision von der minimalen Version
|
|
zu entfernen, so dass Backports mit einer niedrigeren Versionsnummer aber
|
|
der gleichen Version der Originalautoren immer noch die erstellten
|
|
Abhängigkeiten erfüllen. Falls die Debian-Revision nicht entfernt werden
|
|
kann, da das Symbol wirklich von der Debian-spezifischen Änderung
|
|
hinzugefügt wurde, dann sollte der Version bq<B>~</B>' angehängt werden.
|
|
<P>
|
|
|
|
Bevor irgendein Patch auf die Symboldatei angewendet wird, sollte der
|
|
Betreuer zweimal prüfen, dass der Patch vernünftig ist. Öffentliche Symbole
|
|
sollten nicht verschwinden, daher sollte der Patch idealerweise nur neue
|
|
Zeilen hinzufügen.
|
|
<P>
|
|
|
|
Beachten Sie, dass Sie in Symboldateien Kommentare einfügen können: jede
|
|
Zeile, die mit bq#' als ersten Zeichen beginnt, ist ein Kommentar, falls sie
|
|
nicht mit bq#include' beginnt (siehe Abschnitt <B>Includes
|
|
verwenden</B>). Zeilen, die mit bq#MISSING:' anfangen, sind besondere
|
|
Kommentare, die verschwundene Symbole dokumentieren.
|
|
<P>
|
|
|
|
Vergessen Sie nicht, zu überprüfen, ob alte Versionen aktualisiert werden
|
|
müssen. Es gibt für <B>dpkg-gensymbols</B> keine Möglichkeit, hierzu eine
|
|
Warnung auszugeben. Wird der Diff blind akzeptiert oder wird angenommen,
|
|
dass nichts geändert werden muss, wenn es keinen Diff gibt, ohne auf
|
|
Änderungen zu prüfen, kann dies dazu führen, dass lockere Abhängigkeiten
|
|
erzeugt werden, laut deren mit älteren Versionen gearbeitet werden kann,
|
|
obwohl dies nicht möglich ist. Dies wird zu schwer zu findenden Fehlern bei
|
|
(teilweisen) Upgrades führen.
|
|
<A NAME="lbAF"> </A>
|
|
<H3>Verwendung der #PACKAGE#-Ersetzung</H3>
|
|
|
|
<P>
|
|
|
|
In einigen seltenen Fällen unterscheidet sich der Name der Bibliothek auf
|
|
verschiedenen Architekturen. Um zu vermeiden, dass der Paketname in der
|
|
Symboldatei fest kodiert wird, können Sie die Markierung <I>#PACKAGE#</I>
|
|
verwenden. Während der Installation der Symboldatei wird sie durch den
|
|
echten Paketnamen ersetzt. Anders als die Markierung <I>#MINVER#</I> wird
|
|
<I>#PACKAGE#</I> nie in der Symboldatei innerhalb eines Binärpakets auftauchen.
|
|
<A NAME="lbAG"> </A>
|
|
<H3>Verwendung von Symbolkennzeichnungen</H3>
|
|
|
|
<P>
|
|
|
|
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 <B>dpkg-gensymbols</B>
|
|
verstanden und lösen eine Spezialbehandlung der Symbole aus. Lesen Sie den
|
|
Unterabschnit <B>Standardsymbolkennzeichnungen</B> für eine Referenz dieser
|
|
Kennzeichnungen.
|
|
<P>
|
|
|
|
Kennzeichnungsspezifikationen kommen direkt vor dem Symbolnamen (dazwischen
|
|
sind keine Leerraumzeichen erlaubt). Sie beginnen immer mit einer öffnenden
|
|
Klammer <B>(</B>, enden mit einer schließenden Klammer <B>)</B> und müssen
|
|
mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden
|
|
durch das Zeichen <B>|</B> getrennt. Jede Kennzeichnungen kann optional einen
|
|
Wert enthalten, der von der Kennzeichnung durch das Zeichen <B>=</B> getrennt
|
|
wird. Kennzeichennamen und -werte können beliebige Zeichenketten sein, sie
|
|
dürfen allerdings keine der der besonderen Zeichen <B>)</B> <B>|</B> <B>=</B>
|
|
enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, können
|
|
optional mit den Zeichen <B>'</B> oder <B>"</B> zitiert werden, um Leerraumzeichen
|
|
darin zu erlauben. Falls keine Kennzeichnungen für das Symbol spezifiziert
|
|
sind, werden Zitatzeichen als Teil des Symbolnamens behandelt, der bis zum
|
|
ersten Leerzeichen geht.
|
|
<P>
|
|
|
|
<BR> (Kennz1=bin markiert|Name mit Leerraum)"zitiertes gekennz Symbol"@Base 1.0
|
|
<BR> (optional)<A HREF="mailto:gekennzeichnet_unzitiertes_Symbol@Base">gekennzeichnet_unzitiertes_Symbol@Base</A> 1.0 1
|
|
<BR> <A HREF="mailto:ungekennzeichnetes_Symbol@Base">ungekennzeichnetes_Symbol@Base</A> 1.0
|
|
<P>
|
|
|
|
Das erste Symbol im Beispiel heißt <I>zitiertes gekennz Symbol</I> und hat zwei
|
|
Kennzeichnungen: <I>Kennz1</I> mit dem Wert <I>bin markiert</I> und <I>Name mit
|
|
Leerraum</I> ohne Wert. Das zweite Symbol heißt
|
|
<I>gekennzeichnet_unzitiertes_Symbol</I> und ist nur mit dem Kennzeichen namens
|
|
<I>optional</I> gekennzeichnet. Das letzte Symbol ist ein Beispiel eines
|
|
normalen, nicht gekennzeichneten Symbols.
|
|
<P>
|
|
|
|
Da Symbolkennzeichnungen eine Erweiterung des Formats <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A>(5)</B>
|
|
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 <B>dpkg-gensymbols</B>
|
|
ohne die Option <B>-t</B> aufgerufen wird, wird es alle Symbole ausgeben, die
|
|
zum Format <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(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 (<B>-t</B>) in der Ausgabe beibehalten und in
|
|
ihrer Originalform wie sie geladen wurden auch geschrieben.
|
|
<A NAME="lbAH"> </A>
|
|
<H3>Standard-Symbolkennzeichnungen</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="5"><B>optional</B><DD>
|
|
Ein als »optional« gekennzeichnetes Symbol kann jederzeit von der Bibliothek
|
|
verschwinden und wird nie zum Fehlschlag von <B>dpkg-gensymbols</B>
|
|
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, dass bisher als MISSING bezeichnet gewesen
|
|
war, plötzlich in der nächsten Version wieder auftaucht, wird es wieder auf
|
|
den Status Bqexisting" (existierend) gebracht, wobei die minimale Version
|
|
unverändert bleibt.
|
|
<P>
|
|
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.
|
|
<DT id="6"><B>arch=</B><I>Architekturliste</I><DD>
|
|
|
|
<B>arch-bits=</B><I>Architektur-Bits</I>
|
|
|
|
<B>arch-endian=</B><I>Architektur-Endianness</I>
|
|
Diese Markierungen erlauben es, den Satz an Architekturen einzugrenzen, auf
|
|
denen das Symbol existieren sollte. Die Markierungen <B>arch-bits</B> und
|
|
<B>arch-endian</B> werden seit Dpkg 1.18.0 unterstützt. Wenn die Symbolliste mit
|
|
den in der Bibliothek entdeckten Symbolen aktualisiert wird, werden alle
|
|
architekturspezifischen Symbole, die nicht auf die aktuelle Host-Architektur
|
|
passen, so behandelt, als ob sie nicht existierten. Falls ein
|
|
architekturspezifisches Symbol, das auf die aktuelle Host-Architektur passt,
|
|
in der Bibliothek nicht existiert, werden die normalen Regeln für fehlende
|
|
Symbole angewandt und <B>dpkg-gensymbols</B> könnte dadurch fehlschlagen. Auf
|
|
der anderen Seite, falls das architekturspezifische Symbol gefunden wurde,
|
|
wenn es nicht existieren sollte (da die aktuelle Host-Architektur nicht in
|
|
der Markierung aufgeführt ist oder nicht auf die Endianess und Bits passt),
|
|
wird sie architekturneutral gemacht (d.h. die Architektur-,
|
|
Architektur-Bits- und Architektur-Endianessmarkierungen werden entfernt und
|
|
das Symbol wird im Diff aufgrund dieser Änderung auftauchen), aber es wird
|
|
nicht als neu betrachtet.
|
|
<P>
|
|
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.
|
|
<P>
|
|
Das Format der <I>Architekturliste</I> ist das gleiche wie das des Feldes
|
|
<B>Build-Depends</B> in <I>debian/control</I> (außer den einschließenden eckigen
|
|
Klammern []). Beispielsweise wird das erste Symbol aus der folgenden Liste
|
|
nur auf den Architekturen Alpha, Any-amd64 und Ia64 betrachtet, das zweite
|
|
nur Linux-Architekturen, während das dritte überall außer auf Armel
|
|
betrachtet wird.
|
|
<P>
|
|
<BR> (arch=alpha any-amd64 ia64)<A HREF="mailto:64bit_specific_symbol@Base">64bit_specific_symbol@Base</A> 1.0
|
|
<BR> (arch=linux-any)<A HREF="mailto:linux_specific_symbol@Base">linux_specific_symbol@Base</A> 1.0
|
|
<BR> (arch=!armel)<A HREF="mailto:symbol_armel_does_not_have@Base">symbol_armel_does_not_have@Base</A> 1.0
|
|
<P>
|
|
<I>architecture-bits</I> ist entweder <B>32</B> oder <B>64</B>.
|
|
<P>
|
|
<BR> (arch-bits=32)<A HREF="mailto:32bit_specific_symbol@Base">32bit_specific_symbol@Base</A> 1.0
|
|
<BR> (arch-bits=64)<A HREF="mailto:64bit_specific_symbol@Base">64bit_specific_symbol@Base</A> 1.0
|
|
<P>
|
|
<I>architecture-endianness</I> ist entweder <B>little</B> oder <B>big</B>.
|
|
<P>
|
|
<BR> (arch-endian=little)<A HREF="mailto:little_endian_specific_symbol@Base">little_endian_specific_symbol@Base</A> 1.0
|
|
<BR> (arch-endian=big)<A HREF="mailto:big_endian_specific_symbol@Base">big_endian_specific_symbol@Base</A> 1.0
|
|
<P>
|
|
Mehrere Einschränkungen können aneinandergehängt werden.
|
|
<P>
|
|
<BR> (arch-bits=32|arch-endian=little)<A HREF="mailto:32bit_le_symbol@Base">32bit_le_symbol@Base</A> 1.0
|
|
<DT id="7"><B>ignore-blacklist</B><DD>
|
|
dpkg-gensymbols verfügt über eine interne Ausschußliste (»blacklist«) von
|
|
Symbolen, die nicht in Symboldateien auftauchen sollten, da sie
|
|
normalerweise nur Seiteneffekte von Implementierungsdetails in der
|
|
Werkzeugkette darstellen. Falls Sie aus irgendeinem Grund wollen, dass diese
|
|
Symbole in der Symboldatei aufgenommen werden, sollten Sie das Symbol mit
|
|
<B>ignore-blacklist</B> kennzeichnen. Dies kann für einige grundlegende
|
|
Bibliotheken der Werkzeugkette wie libgcc notwendig sein.
|
|
<DT id="8"><B>c++</B><DD>
|
|
Gibt <I>c++</I>-Symbolmuster an. Lesen Sie den Unterabschnitt <B>Verwendung von
|
|
Symbolmuster</B> unten.
|
|
<DT id="9"><B>symver</B><DD>
|
|
Gibt <I>symver</I> (Symbolversion)-Symbolmuster an. Lesen Sie den Unterabschnitt
|
|
<B>Verwendung von Symbolmuster</B> unten.
|
|
<DT id="10"><B>regex</B><DD>
|
|
Gibt <I>regex</I>-Symbolmuster an. Lesen Sie den Unterabschnitt <B>Verwendung von
|
|
Symbolmuster</B> unten.
|
|
</DL>
|
|
<A NAME="lbAI"> </A>
|
|
<H3>Verwendung von Symbolmustern</H3>
|
|
|
|
<P>
|
|
|
|
Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale
|
|
Symbole aus der Bibliothek abdecken. <B>dpkg-gensymbols</B> wird versuchen,
|
|
jedes Muster auf jedes reale Symbol, für das <I>kein</I> spezifisches
|
|
Symbolgegenstück in der Symboldatei definiert ist, zu passen. 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.
|
|
<P>
|
|
Ein Muster wird als verloren betrachtet, falls es auf kein Symbol in der
|
|
Bibliothek passt. Standardmäßig wird dies ein Versagen von
|
|
<B>dpkg-gensymbols</B> in der Stufe <B>-c1</B> oder höher auslösen. Falls der
|
|
Fehlschlag allerdings unerwünscht ist, kann das Muster mit der Kennzeichnung
|
|
<I>optional</I> markiert werden. Falls das Muster dann auf nichts passt wird es
|
|
im Diff nur als MISSING (fehlend) auftauchen. Desweiteren kann das Muster
|
|
wie jedes Symbol auf die spezielle Architektur mit der Kennzeichnung <I>arch</I>
|
|
beschränkt werden. Bitte lesen Sie den Unterabschnitt <B>Standard
|
|
Symbolkennzeichnungen</B> oben für weitere Informationen.
|
|
<P>
|
|
Muster sind eine Erweiterung des Formats <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5); sie sind daher
|
|
nur in Symboldatei-Vorlagen gültig. Die Musterspezifikationssyntax
|
|
unterscheidet sich nicht von der eines spezifischen Symbols. Allerdings
|
|
dient der Symbolnamenteil der Spezifikation als Ausdruck, der gegen
|
|
<I><A HREF="mailto:Name@Version">Name@Version</A></I> eines realen Symbols gepasst wird. Um zwischen den
|
|
verschiedenen Mustertypen zu unterscheiden, wird es typischerweise mit einer
|
|
speziellen Kennzeichnung gekennzeichnet.
|
|
<P>
|
|
Derzeit unterstützt <B>dpkg-gensymbols</B> drei grundlegene Mustertypen:
|
|
<DL COMPACT>
|
|
<DT id="11"><B>c++</B><DD>
|
|
Dieses Muster wird durch die Kennzeichnung <I>c++</I> verzeichnet. Es passt nur
|
|
auf die entworrenen (»demangled«) Symbolnamen (wie sie vom Hilfswerkzeug
|
|
<B>c++<A HREF="/cgi-bin/man/man2html?1+filt">filt</A></B>(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 <I>non-virtual thunks</I>, die
|
|
einen architekturspezifischen Versatz in ihren verworrenen Namen eingebettet
|
|
haben. Eine häufige Instanz dieses Falles ist ein virtueller Destruktur, der
|
|
unter rautenförmiger Vererbung ein nicht-virtuelles Thunk-Symbol
|
|
benötigt. Selbst wenn beispielsweise <A HREF="mailto:_ZThn8_N3NSB6ClassDD1Ev@Base">_ZThn8_N3NSB6ClassDD1Ev@Base</A> auf 32
|
|
Bit-Architekturen <A HREF="mailto:_ZThn16_N3NSB6ClassDD1Ev@Base">_ZThn16_N3NSB6ClassDD1Ev@Base</A> auf 64 Bit-Architekturen
|
|
ist, kann es mit einem einzigen <I>c++</I>-Muster gepasst werden:
|
|
<P>
|
|
libdummy.so.1 libdummy1 #MINVER#
|
|
<BR> […]
|
|
<BR> (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
|
|
<BR> […]
|
|
<P>
|
|
Der entworrene Name oben kann durch Ausführung folgenden Befehls erhalten
|
|
werden:
|
|
<P>
|
|
<BR> $ echo '<A HREF="mailto:_ZThn8_N3NSB6ClassDD1Ev@Base">_ZThn8_N3NSB6ClassDD1Ev@Base</A>' | c++filt
|
|
<P>
|
|
Bitte beachten Sie, dass per Definition zwar der verworrene Name in der
|
|
Bibliothek eindeutig ist, die aber nicht notwendigerweise für die
|
|
entworrenen Namen zutrifft. Ein Satz von unterschiedlichen realen Symbolen
|
|
können den gleichen entworrenen Namen haben. Beispielsweise ist das der Fall
|
|
bei nicht-virtuellen Thunk-Symbolen in komplexen Vererbungskonfigurationen
|
|
oder bei den meisten Konstruktoren und Destruktoren (da g++ typischerweise
|
|
zwei reale Symbole für sie generiert). Da diese Kollisionen aber auf dem
|
|
ABI-Niveau passieren, sollten sie nicht die Qualität der Symboldatei
|
|
reduzieren.
|
|
<DT id="12"><B>symver</B><DD>
|
|
Dieses Muster wird durch die Kennzeichnung <I>symver</I> 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 <I>symver</I>-Muster verwenden, um
|
|
auf jedes zu einer spezifizierten Version zugeordnete Symbol zu
|
|
passen. Beispiel:
|
|
<P>
|
|
libc.so.6 libc6 #MINVER#
|
|
<BR> (symver)GLIBC_2.0 2.0
|
|
<BR> […]
|
|
<BR> (symver)GLIBC_2.7 2.7
|
|
<BR> <A HREF="mailto:access@GLIBC_2.0">access@GLIBC_2.0</A> 2.2
|
|
<P>
|
|
Alle Version GLIBC_2.0 und GLIBC_2.7 zugeordneten Symbole werden zu einer
|
|
minimalen Version 2.0 bzw. 2.7 führen, wobei das Symbol <A HREF="mailto:access@GLIBC_2.0">access@GLIBC_2.0</A> 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« passt, da spezielle Symbole vor Mustern Vorrang haben.
|
|
<P>
|
|
Bitte beachten Sie, dass Platzhaltermuster im alten Format (angezeigt durch
|
|
»*@version« im Symbolnamenfeld) zwar noch unterstützt werden, sie aber durch
|
|
die Syntax im neuen Format »(symver|optional)version« abgelöst
|
|
wurden. Beispielsweise sollte »*@GLIBC_2.0 2.0« als
|
|
»(symver|optional)GLIBC_2.0 2.0« geschrieben werden, falls das gleiche
|
|
Verhalten benötigt wird.
|
|
<DT id="13"><B>regex</B><DD>
|
|
Muster mit regulären Ausdrücken werden durch die Kennzeichnung <I>regex</I>
|
|
verzeichnet. Sie passen auf den regulären Ausdruck von Perl, der im
|
|
Symbolnamenfeld angegeben ist. Ein regulärer Ausdruck wird wie er ist
|
|
gepasst. Denken Sie daher daran, ihn mit dem Zeichen <I>^</I> zu beginnen, da er
|
|
ansonsten auf jeden Teil der Zeichenkette des realen Symbols <I><A HREF="mailto:name@version">name@version</A></I>
|
|
passt. Beispiel:
|
|
<P>
|
|
libdummy.so.1 libdummy1 #MINVER#
|
|
<BR> (regex)"^mystack_.*@Base$" 1.0
|
|
<BR> (regex|optional)"private" 1.0
|
|
<P>
|
|
Symbole wie »<A HREF="mailto:mystack_new@Base">mystack_new@Base</A>«, »<A HREF="mailto:mystack_push@Base">mystack_push@Base</A>«, »<A HREF="mailto:mystack_pop@Base">mystack_pop@Base</A>«
|
|
usw. werden vom ersten Muster gepasst, während dies z.B. für
|
|
»<A HREF="mailto:ng_mystack_new@Base">ng_mystack_new@Base</A>« nicht der Fall ist. Das zweite Muster wird auf alle
|
|
Symbole, die die Zeichenkette »private« in ihren Namen enthalten, passen und
|
|
die gepassten Symbole erben die Kennzeichnung <I>optional</I> vom Muster.
|
|
</DL>
|
|
<P>
|
|
|
|
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
|
|
<P>
|
|
<BR> (c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
|
|
<BR> (regex|c++)N3NSA6ClassA7Private11privmethod\<A HREF="mailto:dEi@Base">dEi@Base</A> 1.0
|
|
<P>
|
|
werden die Symbole »<A HREF="mailto:_ZN3NSA6ClassA7Private11privmethod1Ei@Base">_ZN3NSA6ClassA7Private11privmethod1Ei@Base</A>« und
|
|
»<A HREF="mailto:_ZN3NSA6ClassA7Private11privmethod2Ei@Base">_ZN3NSA6ClassA7Private11privmethod2Ei@Base</A>« gepasst. Beim Passen der ersten
|
|
Musters wird das rohe Symbol erst als C++-Symbol entworren, dann wird der
|
|
entworrende Name gegen den regulären Ausdruck gepasst. Auf der anderen Seite
|
|
wird beim Passen des zweiten Musters der reguläre Ausdruck gegen den rohen
|
|
Symbolnamen gepasst, 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\<A HREF="mailto:dEi@Base">dEi@Base</A>« keines der
|
|
Muster passen, da es kein gültiges C++-Symbol ist.
|
|
<P>
|
|
Im Allgemeinen werden die Muster in zwei Kategorien eingeteilt: Aliase
|
|
(grundlegende <I>c++</I>- und <I>symver</I>-Muster) und generische Muster (<I>regex</I>
|
|
und alle Kombinationen grundlegender Muster). Passen von grundlegenden
|
|
alias-basierenden Mustern ist schnell (<A HREF="/cgi-bin/man/man2html?1+O">O</A>(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.
|
|
<P>
|
|
Wenn mehrere Muster auf das gleiche Symbol passen, werden Aliase (zuerst
|
|
<I>c++</I>, dann <I>symver</I>) gegenüber den generischen Mustern
|
|
bevorzugt. Generische Muster werden in der Reihenfolge, in der sie in der
|
|
Symboldateivorlage gefunden werden, gepasst, bis zum ersten Erfolg. Beachten
|
|
Sie aber, dass das manuelle Anordnen der Vorlagendateieinträge nicht
|
|
empfohlen wird, da <B>dpkg-gensymbols</B> Diffs basierend auf der
|
|
alphanumerischen Reihenfolge ihrer Namen erstellt.
|
|
<A NAME="lbAJ"> </A>
|
|
<H3>Includes verwenden</H3>
|
|
|
|
<P>
|
|
|
|
Wenn der Satz der exportierten Symbolen 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:
|
|
<DL COMPACT>
|
|
<DT id="14">•<DD>
|
|
Sie können den gemeinsamen Teil in eine externe Datei auslagern und diese
|
|
Datei dann in Ihre <I>Paket</I>.symbols.<I>Arch</I>-Datei mit einer
|
|
include-Direktive wie folgt einbinden:
|
|
<P>
|
|
#include "<I>Pakete</I>.symbols.common"
|
|
<DT id="15">•<DD>
|
|
Die Include-Direktive kann auch wie jedes Symbol gekennzeichnet werden:
|
|
<P>
|
|
(Kennzeichen|…|KennzeichenN)#include "einzubindende-Datei"
|
|
<P>
|
|
Als Ergebnis werden alle Symbole aus <I>einzubindende-Datei</I> standardmäßig
|
|
als mit <I>Kennzeichen</I> … <I>KennzeichenN</I> gekennzeichnet betrachtet. Sie
|
|
können diese Funktionalität benutzen, um eine gemeinsame Datei
|
|
<I>Paket</I>.symbols zu erstellen, die architekturspezifische Symboldateien
|
|
einbindet:
|
|
<P>
|
|
<BR> <A HREF="mailto:common_symbol1@Base">common_symbol1@Base</A> 1.0
|
|
<BR> (arch=amd64 ia64 alpha)#include "Paket.symbols.64bit"
|
|
<BR> (arch=!amd64 !ia64 !alpha)#include "Paket.symbols.32bit"
|
|
<BR> <A HREF="mailto:common_symbol2@Base">common_symbol2@Base</A> 1.0
|
|
</DL>
|
|
<P>
|
|
|
|
Die Symboldateien werden Zeile für Zeile gelesen und include-Direktiven
|
|
werden bearbeitet, sobald sie erkannt werden. Das bedeutet, dass der Inhalt
|
|
der Include-Datei jeden Inhalt überschreiben kann, der vor der
|
|
Include-Direktive aufgetaucht ist und Inhalt nach der Direktive alles aus
|
|
der Include-Datei überschreiben kann. Jedes Symbol (oder sogar weitere
|
|
#include-Direktiven) in der Include-Datei kann zusätzliche Kennzeichnungen
|
|
spezifizieren oder Werte der vererbtgen Kennzeichnungen in ihrer
|
|
Kennzeichnungsspezifikation überschreiben. Allerdings gibt es keine
|
|
Möglichkeit für ein Symbol, die ererbten Kennzeichnungen zu überschreiben.
|
|
<P>
|
|
|
|
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. Ein Weg dies zu erreichen, ist wie folgt:
|
|
<P>
|
|
|
|
#include "libirgendwas1.symbols.common"
|
|
<BR> <A HREF="mailto:arch_spezifisches_Symbol@Base">arch_spezifisches_Symbol@Base</A> 1.0
|
|
<A NAME="lbAK"> </A>
|
|
<H3>Gute Bibliotheksverwaltung</H3>
|
|
|
|
<P>
|
|
|
|
Eine gut verwaltete Bibliothek hat die folgenden Eigenschaften:
|
|
<DL COMPACT>
|
|
<DT id="16">•<DD>
|
|
seine API ist stabil (öffentliche Symbole entfallen nie, nur neue
|
|
öffentliche Symbole werden hinzugefügt) und inkompatible Änderungen erfolgen
|
|
nur, wenn sich der SONAME ändert,
|
|
<DT id="17">•<DD>
|
|
idealerweise verwendet sie Symbolversionierung, um ABI-Stabilität trotz
|
|
interner Änderungen und API-Erweiterungen zu erreichen,
|
|
<DT id="18">•<DD>
|
|
sie exportiert nie private Symbole (als Hilfslösung können diese als
|
|
optional gekennzeichnet werden).
|
|
</DL>
|
|
<P>
|
|
|
|
Bei der Verwaltung der Symboldatei kann das Auftauchen und Verschwinden von
|
|
Symbolen leicht bemerkt werden. Es ist aber schwieriger, inkompatbile API-
|
|
und ABI-Änderungen zu bemerken. Daher sollte der Betreuer intensiv die
|
|
Changelog-Einträge durchschauen und nach Fällen suchen, in denen die Regeln
|
|
der guten Bibliotheksverwaltung gebrochen wurden. Falls mögliche Probleme
|
|
entdeckt wurden, sollten der Originalautor informiert werden, da eine
|
|
Korrektur vom Originalautor immer besser als eine Debian-spezifische
|
|
Hilfslösung ist.
|
|
<A NAME="lbAL"> </A>
|
|
<H2>OPTIONEN</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="19"><B>-P</B><I>Paketbauverzeichnis</I><DD>
|
|
Suche nach <I>Paketbauverzeichnis</I> statt nach debian/tmp.
|
|
<DT id="20"><B>-p</B><I>Paket</I><DD>
|
|
Definiert den Paketnamen. Benötigt, falls mehr als ein binäres Paket in
|
|
debian/control aufgeführt ist (oder falls es keine Datei debian/control
|
|
gibt).
|
|
<DT id="21"><B>-v</B><I>Version</I><DD>
|
|
Definiert die Paketversion. Standardmäßig wird die Version aus
|
|
debian/changelog entnommen. Benötigt, falls der Aufruf außerhalb des
|
|
Quellpaketbaums erfolgt.
|
|
<DT id="22"><B>-e</B><I>Bibliotheksdatei</I><DD>
|
|
Nur die explizit aufgeführten Bibliotheken untersuchen statt alle
|
|
öffentlichen Bibliotheken zu finden. Sie können Shell-Muster, die zur
|
|
Expansion von Pfadnamen verwandt werden (siehe die Handbuchseite
|
|
<B>File::Glob</B>(3perl) für weitere Details) in <I>Bibliotheksdatei</I> verwenden,
|
|
um mehrere Bibliotheken mit einem einzelnen Argument zu passen (andernfalls
|
|
benötigen Sie mehrere <B>-e</B>).
|
|
<DT id="23"><B>-l</B><I>Verzeichnis</I><DD>
|
|
Stellt <I>Verzeichnis</I> der Liste der zu durchsuchenden privaten
|
|
Laufzeitbibliotheken voran (seit Dpkg 1.19.1). Diese Option kann mehrfach
|
|
angegeben werden.
|
|
<P>
|
|
Hinweis: Verwenden Sie diese Variable, statt <B>LD_LIBRARY_PATH</B> zu setzten,
|
|
da diese Umgebungsvariable verwandt wird, um den Laufzeit-Linker zu steuern
|
|
und ihr Missbrauch zum Setzen von Pfaden zu Laufzeitbibliotheken zur Bauzeit
|
|
kann beispielsweise beim Cross-Übersetzen problematisch werden.
|
|
<DT id="24"><B>-I</B><I>Dateiname</I><DD>
|
|
Verwende <I>Dateiname</I> als Referenzdatei, um die Symboldatei zu erstellen,
|
|
die dann im Paket selbst integriert wird.
|
|
<DT id="25"><B>-O</B>[<I>Dateiname</I>]<DD>
|
|
Die erstellte Symbols-Datei auf die Standardausgabe oder nach <I>Dateiname</I>,
|
|
falls angegeben, ausgeben statt in <B>debian/tmp/DEBIAN/symbols</B> (oder
|
|
<I>Paket-Bauverzeichnis</I><B>/DEBIAN/symbols</B> falls <B>-P</B> verwandt wurde). Falls
|
|
<I>Dateiname</I> bereits existiert, wird deren Inhalt als Grundlage für die
|
|
erstellte Symboldatei verwandt. Sie können diese Funktionalität benutzen, um
|
|
eine Symboldatei zu aktualisieren, so dass sie zu einer neueren Version der
|
|
Originalautoren Ihrer Bibliothek passt.
|
|
<DT id="26"><B>-t</B><DD>
|
|
Schreibe die Symboldatei im Vorlagenmodus statt im zu <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5)
|
|
kompatiblen Format. Der Hauptunterschied besteht darin, dass im
|
|
Vorlagenmodus die Symbolnamen und Kennzeichnungen in ihrer Originalform
|
|
geschrieben werden, im Gegensatz zu den verarbeiteten Symbolnamen mit
|
|
entfernen Kennzeichnungen im Kompatibilitätsmodus. Desweiteren könnten
|
|
einige Symbole beim Schreiben einer Standard <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5)-Datei
|
|
entfernt werden (gemäß der Verarbeitungsregeln für Kennzeichen), während in
|
|
der Symboldateivorlage immer alle Symbole geschrieben werden.
|
|
<DT id="27"><B>-c</B><I>[0-4]</I><DD>
|
|
Definiert die Prüfungen, die beim Vergleich der erstellten Symboldatei mit
|
|
der Vorlagendatei als Startpunkt erfolgen sollen. Standardstufe ist
|
|
1. Zunehmende Stufen führen mehr Prüfungen durch und enthalten alle
|
|
Prüfungen der niedrigeren Stufen. Stufe 0 schlägt nie fehl. Stufe 1 schlägt
|
|
fehl, wenn einige Symbole verschwunden sind. Stufe 2 schlägt fehlt, falls
|
|
einige neue Symbole eingeführt wurden. Stufe 3 schlägt fehl, falls einige
|
|
Bibliotheken verschwunden sind. Stufe 4 schlägt fehl, falls einige
|
|
Bibliotheken hinzugekommen sind.
|
|
<P>
|
|
Dieser Wert kann von der Umgebungsvariablen <B>DPKG_GENSYMBOLS_CHECK_LEVEL</B>
|
|
außer Kraft gesetzt werden.
|
|
<DT id="28"><B>-q</B><DD>
|
|
Ruhig verhalten und nie einen Diff zwischen der erstellten Symboldatei und
|
|
der als Startpunkt verwandten Vorlagendatei erstellen oder keine Warnungen
|
|
bezüglich neuer/verlorender Bibliotheken oder neuer/verlorender Symbole
|
|
ausgeben. Diese Option deaktiviert nur die informative Ausgabe aber nicht
|
|
die Prüfungen selbst (sehen Sie hierzu die Option <B>-c</B>).
|
|
<DT id="29"><B>-a</B><I>Architektur</I><DD>
|
|
Nehme <I>Arch</I> als Host-Architektur beim Verarbeiten der Symboldateien
|
|
an. Verwenden Sie diese Option, um Symboldateien oder Diffs für beliebige
|
|
Architekturen zu erstellen, vorausgesetzt, die Binärprogramme sind bereits
|
|
verfügbar.
|
|
<DT id="30"><B>-d</B><DD>
|
|
Debug-Modus aktivieren. Eine Vielzahl von Nachrichten wird angezeigt, um zu
|
|
erklären, was <B>dpkg-gensymbols</B> durchführt.
|
|
<DT id="31"><B>-V</B><DD>
|
|
Ausführlichen Modus aktivieren. Die erstellte Symboldatei enthält veraltete
|
|
Symbole als Kommentare. Im Vorlagenmodus werden Mustersymbole desweiteren
|
|
von Kommentaren gefolgt, die die echten Symbole aufführen, die auf dieses
|
|
Muster passen.
|
|
<DT id="32"><B>-?</B>, <B>--help</B><DD>
|
|
Zeige den Bedienungshinweis und beende.
|
|
<DT id="33"><B>--version</B><DD>
|
|
Gebe die Version aus und beende sich.
|
|
</DL>
|
|
<A NAME="lbAM"> </A>
|
|
<H2>UMGEBUNG</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="34"><B>DPKG_GENSYMBOLS_CHECK_LEVEL</B><DD>
|
|
Setzt die Befehlsüberprüfungsstufe außer Kraft, selbst wenn das
|
|
Befehlszeilenargument <B>-c</B> übergeben wurde (beachten Sie, dass dies der
|
|
üblichen Konvention widerspricht, demnach Befehlszeilenargumente Vorrang
|
|
über Umgebungsvariablen haben).
|
|
<DT id="35"><B>DPKG_COLORS</B><DD>
|
|
Setzt den Farbmodus (seit Dpkg 1.18.5). Die derzeit unterstützten Werte
|
|
sind: <B>auto</B> (Vorgabe), <B>always</B> und <B>never</B>.
|
|
<DT id="36"><B>DPKG_NLS</B><DD>
|
|
Falls dies gesetzt ist, wird es zur Entscheidung, ob Native Language
|
|
Support, auch als Internationalisierung (oder i18n) Unterstützung bekannt,
|
|
aktiviert wird (seit Dpkg 1.19.0). Die akzeptierten Werte sind: <B>0</B> und
|
|
<B>1</B> (Vorgabe).
|
|
</DL>
|
|
<A NAME="lbAN"> </A>
|
|
<H2>SIEHE AUCH</H2>
|
|
|
|
<B><A HREF="https://people.redhat.com/drepper/symbol-versioning">https://people.redhat.com/drepper/symbol-versioning</A></B>
|
|
<BR>
|
|
|
|
<B><A HREF="https://people.redhat.com/drepper/goodpractice.pdf">https://people.redhat.com/drepper/goodpractice.pdf</A></B>
|
|
<BR>
|
|
|
|
<B><A HREF="https://people.redhat.com/drepper/dsohowto.pdf">https://people.redhat.com/drepper/dsohowto.pdf</A></B>
|
|
<BR>
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5), <B><A HREF="/cgi-bin/man/man2html?1+dpkg-shlibdeps">dpkg-shlibdeps</A></B>(1).
|
|
<A NAME="lbAO"> </A>
|
|
<H2>ÜBERSETZUNG</H2>
|
|
|
|
Die deutsche Übersetzung wurde 2004, 2006-2019 von Helge Kreutzmann
|
|
<<A HREF="mailto:debian@helgefjell.de">debian@helgefjell.de</A>>, 2007 von Florian Rehnisch <<A HREF="mailto:eixman@gmx.de">eixman@gmx.de</A>> und
|
|
2008 von Sven Joachim <<A HREF="mailto:svenjoac@gmx.de">svenjoac@gmx.de</A>>
|
|
angefertigt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die
|
|
GNU General Public License Version 2 oder neuer für die Kopierbedingungen.
|
|
Es gibt KEINE HAFTUNG.
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="37"><A HREF="#lbAB">BEZEICHNUNG</A><DD>
|
|
<DT id="38"><A HREF="#lbAC">ÜBERSICHT</A><DD>
|
|
<DT id="39"><A HREF="#lbAD">BESCHREIBUNG</A><DD>
|
|
<DT id="40"><A HREF="#lbAE">SYMBOLDATEIEN PFLEGEN</A><DD>
|
|
<DL>
|
|
<DT id="41"><A HREF="#lbAF">Verwendung der #PACKAGE#-Ersetzung</A><DD>
|
|
<DT id="42"><A HREF="#lbAG">Verwendung von Symbolkennzeichnungen</A><DD>
|
|
<DT id="43"><A HREF="#lbAH">Standard-Symbolkennzeichnungen</A><DD>
|
|
<DT id="44"><A HREF="#lbAI">Verwendung von Symbolmustern</A><DD>
|
|
<DT id="45"><A HREF="#lbAJ">Includes verwenden</A><DD>
|
|
<DT id="46"><A HREF="#lbAK">Gute Bibliotheksverwaltung</A><DD>
|
|
</DL>
|
|
<DT id="47"><A HREF="#lbAL">OPTIONEN</A><DD>
|
|
<DT id="48"><A HREF="#lbAM">UMGEBUNG</A><DD>
|
|
<DT id="49"><A HREF="#lbAN">SIEHE AUCH</A><DD>
|
|
<DT id="50"><A HREF="#lbAO">ÜBERSETZUNG</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:04:56 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|