.\" dpkg manual page - dpkg-gensymbols(1) .\" .\" Copyright © 2007-2011 Rapha\(:el Hertzog .\" Copyright © 2009-2010 Modestas Vainius .\" Copyright © 2012-2015 Guillem Jover .\" .\" This is free software; you can redistribute it and/or modify .\" it under the terms of the GNU General Public License as published by .\" the Free Software Foundation; either version 2 of the License, or .\" (at your option) any later version. .\" .\" This is distributed in the hope that it will be useful, .\" but WITHOUT ANY WARRANTY; without even the implied warranty of .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .\" GNU General Public License for more details. .\" .\" You should have received a copy of the GNU General Public License .\" along with this program. If not, see . . .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH dpkg\-gensymbols 1 2019-06-03 1.19.7 dpkg\-Programmsammlung .nh .SH BEZEICHNUNG dpkg\-gensymbols \- erstelle Symboldateien (Abh\(:angigkeitsinformationen f\(:ur Laufzeitbibliotheken) . .SH \(:UBERSICHT \fBdpkg\-gensymbols\fP [\fIOption\fP …] . .SH BESCHREIBUNG \fBdpkg\-gensymbols\fP durchsucht einen tempor\(:aren Baubaum (standardm\(:a\(ssig debian/tmp), sucht nach Bibliotheken und erstellt eine Datei \fIsymbols\fP, 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): .IP \(bu 4 debian/\fIPaket\fP.symbols.\fIArchitektur\fP .IP \(bu 4 debian/symbols.\fIArchitektur\fP .IP \(bu 4 debian/\fIPaket\fP.symbols .IP \(bu 4 debian/symbols .P Der Hauptzweck dieser Dateien besteht darin, die minimale Version bereitzustellen, die mit jedem von der Bibliothek bereitgestellten Symbol verkn\(:upft ist. Normalerweise entspricht dies der ersten Version des Pakets, die dieses Symbol bereitgestellt hat, kann aber vom Betreuer erh\(:oht werden, falls die ABI des Symbols ohne Brechen der R\(:uckw\(:artskompatibilit\(:at erweitert wurde. Es liegt in der Verwantwortung des Betreuers, diese Dateien aktuell zu halten, aber \fBdpkg\-gensymbols\fP hilft dabei. .P Wenn die erstellten Symboldateien sich von denen, die der Betreuer bereitgestellt hat, unterscheiden, wird \fBdpkg\-gensymbols\fP ein Diff zwischen den zwei Versionen anzeigen. Falls die Unterschiede desweiteren zu gravierend sind, wird es sogar fehlschlagen (Sie k\(:onnen einstellen, wie gro\(sse Unterschiede Sie tolerieren k\(:onnen, sehen Sie hierzu die Option \fB\-c\fP). .SH "SYMBOLDATEIEN PFLEGEN" Die Symboldateien sind nur wirklich n\(:utzlich, falls sie die Entwicklung eines Paketes \(:uber mehrere Ver\(:offentlichungen hinweg wiedergeben. Daher muss der Betreuer sie immer aktualisieren, wenn eine neues Symbol hinzugef\(:ugt wird, so dass die zugeordnete minimale Version der Realit\(:at entspricht. Die in den Bauprotokollen enthaltenen Diffs k\(:onnen als Startpunkt benutzt werden, aber zus\(:atzlich hat der Betreuer sicherzustellen, dass sich das Verhalten dieser Symbole nicht derart ge\(:andert hat, dass irgendetwas, was diese Symbole verwendet und gegen die neue Version gelinkt ist, daran hindern w\(:urde, mit der alten Version zu funktionieren. Meistens kann der Diff direkt auf die Datei debian/\fIPaket\fP.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\(:angigkeiten erf\(:ullen. Falls die Debian\-Revision nicht entfernt werden kann, da das Symbol wirklich von der Debian\-spezifischen \(:Anderung hinzugef\(:ugt wurde, dann sollte der Version \(bq\fB~\fP\(cq angeh\(:angt werden. .P Bevor irgendein Patch auf die Symboldatei angewendet wird, sollte der Betreuer zweimal pr\(:ufen, dass der Patch vern\(:unftig ist. \(:Offentliche Symbole sollten nicht verschwinden, daher sollte der Patch idealerweise nur neue Zeilen hinzuf\(:ugen. .P Beachten Sie, dass Sie in Symboldateien Kommentare einf\(:ugen k\(:onnen: jede Zeile, die mit \(bq#\(cq als ersten Zeichen beginnt, ist ein Kommentar, falls sie nicht mit \(bq#include\(cq beginnt (siehe Abschnitt \fBIncludes verwenden\fP). Zeilen, die mit \(bq#MISSING:\(cq anfangen, sind besondere Kommentare, die verschwundene Symbole dokumentieren. .P Vergessen Sie nicht, zu \(:uberpr\(:ufen, ob alte Versionen aktualisiert werden m\(:ussen. Es gibt f\(:ur \fBdpkg\-gensymbols\fP keine M\(:oglichkeit, hierzu eine Warnung auszugeben. Wird der Diff blind akzeptiert oder wird angenommen, dass nichts ge\(:andert werden muss, wenn es keinen Diff gibt, ohne auf \(:Anderungen zu pr\(:ufen, kann dies dazu f\(:uhren, dass lockere Abh\(:angigkeiten erzeugt werden, laut deren mit \(:alteren Versionen gearbeitet werden kann, obwohl dies nicht m\(:oglich ist. Dies wird zu schwer zu findenden Fehlern bei (teilweisen) Upgrades f\(:uhren. .SS "Verwendung der #PACKAGE#\-Ersetzung" .P In einigen seltenen F\(:allen unterscheidet sich der Name der Bibliothek auf verschiedenen Architekturen. Um zu vermeiden, dass der Paketname in der Symboldatei fest kodiert wird, k\(:onnen Sie die Markierung \fI#PACKAGE#\fP verwenden. W\(:ahrend der Installation der Symboldatei wird sie durch den echten Paketnamen ersetzt. Anders als die Markierung \fI#MINVER#\fP wird \fI#PACKAGE#\fP nie in der Symboldatei innerhalb eines Bin\(:arpakets auftauchen. .SS "Verwendung von Symbolkennzeichnungen" .P Symbolkennzeichnungen sind n\(:utzlich, um Symbole zu markieren, die in irgendeiner Weise besonders sind. Jedes Symbol kann eine beliebige Anzahl zugeordneter Kennzeichnungen besitzen. W\(:ahrend alle Kennzeichnungen ausgewertet und gespeichert werden, werden nur einige von \fBdpkg\-gensymbols\fP verstanden und l\(:osen eine Spezialbehandlung der Symbole aus. Lesen Sie den Unterabschnit \fBStandardsymbolkennzeichnungen\fP f\(:ur eine Referenz dieser Kennzeichnungen. .P Kennzeichnungsspezifikationen kommen direkt vor dem Symbolnamen (dazwischen sind keine Leerraumzeichen erlaubt). Sie beginnen immer mit einer \(:offnenden Klammer \fB(\fP, enden mit einer schlie\(ssenden Klammer \fB)\fP und m\(:ussen mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden durch das Zeichen \fB|\fP getrennt. Jede Kennzeichnungen kann optional einen Wert enthalten, der von der Kennzeichnung durch das Zeichen \fB=\fP getrennt wird. Kennzeichennamen und \-werte k\(:onnen beliebige Zeichenketten sein, sie d\(:urfen allerdings keine der der besonderen Zeichen \fB)\fP \fB|\fP \fB=\fP enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, k\(:onnen optional mit den Zeichen \fB'\fP oder \fB"\fP zitiert werden, um Leerraumzeichen darin zu erlauben. Falls keine Kennzeichnungen f\(:ur das Symbol spezifiziert sind, werden Zitatzeichen als Teil des Symbolnamens behandelt, der bis zum ersten Leerzeichen geht. .P (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 .P Das erste Symbol im Beispiel hei\(sst \fIzitiertes gekennz Symbol\fP und hat zwei Kennzeichnungen: \fIKennz1\fP mit dem Wert \fIbin markiert\fP und \fIName mit Leerraum\fP ohne Wert. Das zweite Symbol hei\(sst \fIgekennzeichnet_unzitiertes_Symbol\fP und ist nur mit dem Kennzeichen namens \fIoptional\fP gekennzeichnet. Das letzte Symbol ist ein Beispiel eines normalen, nicht gekennzeichneten Symbols. .P Da Symbolkennzeichnungen eine Erweiterung des Formats \fBdeb\-symbols(5)\fP sind, k\(:onnen sie nur Teil der in Quellpaketen verwandten Symboldateien sein (diese Dateien sollten dann als Vorlagen zum Bau der Symboldateien, die in Bin\(:arpakete eingebettet werden, gesehen werden). Wenn \fBdpkg\-gensymbols\fP ohne die Option \fB\-t\fP aufgerufen wird, wird es alle Symbole ausgeben, die zum Format \fBdeb\-symbols\fP(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 (\fB\-t\fP) in der Ausgabe beibehalten und in ihrer Originalform wie sie geladen wurden auch geschrieben. .SS Standard\-Symbolkennzeichnungen .TP \fBoptional\fP Ein als \(Fcoptional\(Fo gekennzeichnetes Symbol kann jederzeit von der Bibliothek verschwinden und wird nie zum Fehlschlag von \fBdpkg\-gensymbols\fP f\(:uhren. Verschwundene optionale Symbole werden kontinuierlich als MISSING (Fehlend) in dem Diff in jeder neuen Paketversion auftauchen. Dieses Verhalten dient als Erinnerung f\(:ur den Betreuer, dass so ein Symbol aus der Symboldatei entfernt oder wieder der Bibliothek hinzugef\(:ugt werden muss. Wenn das optionale Symbol, dass bisher als MISSING bezeichnet gewesen war, pl\(:otzlich in der n\(:achsten Version wieder auftaucht, wird es wieder auf den Status \(Bqexisting\(lq (existierend) gebracht, wobei die minimale Version unver\(:andert bleibt. Diese Markierung ist f\(:ur private Symbole n\(:utzlich, deren Verschwinden keinen ABI\-Bruch ausl\(:ost. Beispielsweise fallen die meisten C++\-Template\-Instanziierungen in diese Kategorie. Wie jede andere Markierung kann auch diese einen beliebigen Wert haben: sie k\(:onnte angeben, warum dieses Symbol als optional betrachtet wird. .TP \fBarch=\fP\fIArchitekturliste\fP .TQ \fBarch\-bits=\fP\fIArchitektur\-Bits\fP .TQ \fBarch\-endian=\fP\fIArchitektur\-Endianness\fP Diese Markierungen erlauben es, den Satz an Architekturen einzugrenzen, auf denen das Symbol existieren sollte. Die Markierungen \fBarch\-bits\fP und \fBarch\-endian\fP werden seit Dpkg 1.18.0 unterst\(:utzt. 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\(:ur fehlende Symbole angewandt und \fBdpkg\-gensymbols\fP k\(:onnte 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\(:uhrt 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 \(:Anderung auftauchen), aber es wird nicht als neu betrachtet. Beim Betrieb im standardm\(:a\(ssigen 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 \fIArchitekturliste\fP ist das gleiche wie das des Feldes \fBBuild\-Depends\fP in \fIdebian/control\fP (au\(sser den einschlie\(ssenden 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\(:ahrend das dritte \(:uberall au\(sser auf Armel betrachtet wird. (arch=alpha any\-amd64 ia64)64bit_specific_symbol@Base 1.0 (arch=linux\-any)linux_specific_symbol@Base 1.0 (arch=!armel)symbol_armel_does_not_have@Base 1.0 \fIarchitecture\-bits\fP ist entweder \fB32\fP oder \fB64\fP. (arch\-bits=32)32bit_specific_symbol@Base 1.0 (arch\-bits=64)64bit_specific_symbol@Base 1.0 \fIarchitecture\-endianness\fP ist entweder \fBlittle\fP oder \fBbig\fP. (arch\-endian=little)little_endian_specific_symbol@Base 1.0 (arch\-endian=big)big_endian_specific_symbol@Base 1.0 Mehrere Einschr\(:ankungen k\(:onnen aneinandergeh\(:angt werden. (arch\-bits=32|arch\-endian=little)32bit_le_symbol@Base 1.0 .TP \fBignore\-blacklist\fP dpkg\-gensymbols verf\(:ugt \(:uber eine interne Ausschu\(ssliste (\(Fcblacklist\(Fo) 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 \fBignore\-blacklist\fP kennzeichnen. Dies kann f\(:ur einige grundlegende Bibliotheken der Werkzeugkette wie libgcc notwendig sein. .TP \fBc++\fP Gibt \fIc++\fP\-Symbolmuster an. Lesen Sie den Unterabschnitt \fBVerwendung von Symbolmuster\fP unten. .TP \fBsymver\fP Gibt \fIsymver\fP (Symbolversion)\-Symbolmuster an. Lesen Sie den Unterabschnitt \fBVerwendung von Symbolmuster\fP unten. .TP \fBregex\fP Gibt \fIregex\fP\-Symbolmuster an. Lesen Sie den Unterabschnitt \fBVerwendung von Symbolmuster\fP unten. .SS "Verwendung von Symbolmustern" .P Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale Symbole aus der Bibliothek abdecken. \fBdpkg\-gensymbols\fP wird versuchen, jedes Muster auf jedes reale Symbol, f\(:ur das \fIkein\fP spezifisches Symbolgegenst\(:uck 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. Ein Muster wird als verloren betrachtet, falls es auf kein Symbol in der Bibliothek passt. Standardm\(:a\(ssig wird dies ein Versagen von \fBdpkg\-gensymbols\fP in der Stufe \fB\-c1\fP oder h\(:oher ausl\(:osen. Falls der Fehlschlag allerdings unerw\(:unscht ist, kann das Muster mit der Kennzeichnung \fIoptional\fP 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 \fIarch\fP beschr\(:ankt werden. Bitte lesen Sie den Unterabschnitt \fBStandard Symbolkennzeichnungen\fP oben f\(:ur weitere Informationen. Muster sind eine Erweiterung des Formats \fBdeb\-symbols\fP(5); sie sind daher nur in Symboldatei\-Vorlagen g\(:ultig. Die Musterspezifikationssyntax unterscheidet sich nicht von der eines spezifischen Symbols. Allerdings dient der Symbolnamenteil der Spezifikation als Ausdruck, der gegen \fIName@Version\fP eines realen Symbols gepasst wird. Um zwischen den verschiedenen Mustertypen zu unterscheiden, wird es typischerweise mit einer speziellen Kennzeichnung gekennzeichnet. Derzeit unterst\(:utzt \fBdpkg\-gensymbols\fP drei grundlegene Mustertypen: .TP 3 \fBc++\fP Dieses Muster wird durch die Kennzeichnung \fIc++\fP verzeichnet. Es passt nur auf die entworrenen (\(Fcdemangled\(Fo) Symbolnamen (wie sie vom Hilfswerkzeug \fBc++filt\fP(1) ausgegeben werden). Dieses Muster ist sehr hilfreich um auf Symbole zu passen, bei dem die verworrenen (\(Fcmangled\(Fo) Namen sich auf verschiedenen Architekturen unterscheiden w\(:ahrend die entworrenen die gleichen bleiben. Eine Gruppe solcher Symbole ist \fInon\-virtual thunks\fP, die einen architekturspezifischen Versatz in ihren verworrenen Namen eingebettet haben. Eine h\(:aufige Instanz dieses Falles ist ein virtueller Destruktur, der unter rautenf\(:ormiger Vererbung ein nicht\-virtuelles Thunk\-Symbol ben\(:otigt. Selbst wenn beispielsweise _ZThn8_N3NSB6ClassDD1Ev@Base auf 32 Bit\-Architekturen _ZThn16_N3NSB6ClassDD1Ev@Base auf 64 Bit\-Architekturen ist, kann es mit einem einzigen \fIc++\fP\-Muster gepasst werden: libdummy.so.1 libdummy1 #MINVER# […] (c++)"non\-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0 […] Der entworrene Name oben kann durch Ausf\(:uhrung folgenden Befehls erhalten werden: $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt Bitte beachten Sie, dass per Definition zwar der verworrene Name in der Bibliothek eindeutig ist, die aber nicht notwendigerweise f\(:ur die entworrenen Namen zutrifft. Ein Satz von unterschiedlichen realen Symbolen k\(:onnen 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\(:ur sie generiert). Da diese Kollisionen aber auf dem ABI\-Niveau passieren, sollten sie nicht die Qualit\(:at der Symboldatei reduzieren. .TP \fBsymver\fP Dieses Muster wird durch die Kennzeichnung \fIsymver\fP verzeichnet. Gut betreute Bibliotheken verf\(:ugen \(:uber versionierte Symbole, wobei jede Version zu der Version der Originalautoren passt, in der dieses Symbol hinzugef\(:ugt wurde. Falls das der Fall ist, k\(:onnen SIe ein \fIsymver\fP\-Muster verwenden, um auf jedes zu einer spezifizierten Version zugeordnete Symbol zu passen. 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 Version GLIBC_2.0 und GLIBC_2.7 zugeordneten Symbole werden zu einer minimalen Version 2.0 bzw. 2.7 f\(:uhren, wobei das Symbol access@GLIBC_2.0 die Ausnahme darstellt. Es wird zu einer minimalen Abh\(:angigkeit auf libc6 Version 2.2 f\(:uhren, obwohl es im Geltungsbereich des Musters \(Fc(symver)GLIBC_2.0\(Fo passt, da spezielle Symbole vor Mustern Vorrang haben. Bitte beachten Sie, dass Platzhaltermuster im alten Format (angezeigt durch \(Fc*@version\(Fo im Symbolnamenfeld) zwar noch unterst\(:utzt werden, sie aber durch die Syntax im neuen Format \(Fc(symver|optional)version\(Fo abgel\(:ost wurden. Beispielsweise sollte \(Fc*@GLIBC_2.0 2.0\(Fo als \(Fc(symver|optional)GLIBC_2.0 2.0\(Fo geschrieben werden, falls das gleiche Verhalten ben\(:otigt wird. .TP \fBregex\fP Muster mit regul\(:aren Ausdr\(:ucken werden durch die Kennzeichnung \fIregex\fP verzeichnet. Sie passen auf den regul\(:aren Ausdruck von Perl, der im Symbolnamenfeld angegeben ist. Ein regul\(:arer Ausdruck wird wie er ist gepasst. Denken Sie daher daran, ihn mit dem Zeichen \fI^\fP zu beginnen, da er ansonsten auf jeden Teil der Zeichenkette des realen Symbols \fIname@version\fP passt. Beispiel: libdummy.so.1 libdummy1 #MINVER# (regex)"^mystack_.*@Base$" 1.0 (regex|optional)"private" 1.0 Symbole wie \(Fcmystack_new@Base\(Fo, \(Fcmystack_push@Base\(Fo, \(Fcmystack_pop@Base\(Fo usw. werden vom ersten Muster gepasst, w\(:ahrend dies z.B. f\(:ur \(Fcng_mystack_new@Base\(Fo nicht der Fall ist. Das zweite Muster wird auf alle Symbole, die die Zeichenkette \(Fcprivate\(Fo in ihren Namen enthalten, passen und die gepassten Symbole erben die Kennzeichnung \fIoptional\fP vom Muster. .P Die oben aufgef\(:uhrten grundlegenden Muster k\(:onnen \- 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\ed\e(int\e)@Base" 1.0 (regex|c++)N3NSA6ClassA7Private11privmethod\edEi@Base 1.0 werden die Symbole \(Fc_ZN3NSA6ClassA7Private11privmethod1Ei@Base\(Fo und \(Fc_ZN3NSA6ClassA7Private11privmethod2Ei@Base\(Fo gepasst. Beim Passen der ersten Musters wird das rohe Symbol erst als C++\-Symbol entworren, dann wird der entworrende Name gegen den regul\(:aren Ausdruck gepasst. Auf der anderen Seite wird beim Passen des zweiten Musters der regul\(:are Ausdruck gegen den rohen Symbolnamen gepasst, dann wird das Symbol \(:uberpr\(:uft, ob es ein C++\-Symbol ist, indem das Entwirren versucht wird. Ein Fehlschlag eines einfachen Musters wird zum Fehlschlag des gesamten Musters f\(:uhren. Daher wird beispielsweise \(Fc__N3NSA6ClassA7Private11privmethod\edEi@Base\(Fo keines der Muster passen, da es kein g\(:ultiges C++\-Symbol ist. Im Allgemeinen werden die Muster in zwei Kategorien eingeteilt: Aliase (grundlegende \fIc++\fP\- und \fIsymver\fP\-Muster) und generische Muster (\fIregex\fP und alle Kombinationen grundlegender Muster). Passen von grundlegenden alias\-basierenden Mustern ist schnell (O(1)), w\(:ahrend generische Muster O(N) (wobei N die Anzahl der generischen Muster ist) f\(:ur jedes Symbol ist. Daher wird empfohlen, generische Muster nicht zu viel zu verwenden. Wenn mehrere Muster auf das gleiche Symbol passen, werden Aliase (zuerst \fIc++\fP, dann \fIsymver\fP) gegen\(:uber 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\(:age nicht empfohlen wird, da \fBdpkg\-gensymbols\fP Diffs basierend auf der alphanumerischen Reihenfolge ihrer Namen erstellt. .SS "Includes verwenden" .P Wenn der Satz der exportierten Symbolen sich zwischen Architekturen unterscheidet, kann es ineffizient werden, eine einzige Symboldatei zu verwenden. In diesen F\(:allen kann sich eine Include\-Direktive in einer Reihe von Arten als n\(:utzlich erweisen: .IP \(bu 4 Sie k\(:onnen den gemeinsamen Teil in eine externe Datei auslagern und diese Datei dann in Ihre \fIPaket\fP.symbols.\fIArch\fP\-Datei mit einer include\-Direktive wie folgt einbinden: #include "\fIPakete\fP.symbols.common" .IP \(bu Die Include\-Direktive kann auch wie jedes Symbol gekennzeichnet werden: (Kennzeichen|…|KennzeichenN)#include "einzubindende\-Datei" Als Ergebnis werden alle Symbole aus \fIeinzubindende\-Datei\fP standardm\(:a\(ssig als mit \fIKennzeichen\fP … \fIKennzeichenN\fP gekennzeichnet betrachtet. Sie k\(:onnen diese Funktionalit\(:at benutzen, um eine gemeinsame Datei \fIPaket\fP.symbols zu erstellen, die architekturspezifische Symboldateien einbindet: common_symbol1@Base 1.0 (arch=amd64 ia64 alpha)#include "Paket.symbols.64bit" (arch=!amd64 !ia64 !alpha)#include "Paket.symbols.32bit" common_symbol2@Base 1.0 .P Die Symboldateien werden Zeile f\(:ur Zeile gelesen und include\-Direktiven werden bearbeitet, sobald sie erkannt werden. Das bedeutet, dass der Inhalt der Include\-Datei jeden Inhalt \(:uberschreiben kann, der vor der Include\-Direktive aufgetaucht ist und Inhalt nach der Direktive alles aus der Include\-Datei \(:uberschreiben kann. Jedes Symbol (oder sogar weitere #include\-Direktiven) in der Include\-Datei kann zus\(:atzliche Kennzeichnungen spezifizieren oder Werte der vererbtgen Kennzeichnungen in ihrer Kennzeichnungsspezifikation \(:uberschreiben. Allerdings gibt es keine M\(:oglichkeit f\(:ur ein Symbol, die ererbten Kennzeichnungen zu \(:uberschreiben. .P Eine eingebundene Datei kann die Kopfzeile wiederholen, die den SONAME der Bibliothek enth\(:alt. In diesem Fall \(:uberschreibt 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: .PP #include "libirgendwas1.symbols.common" arch_spezifisches_Symbol@Base 1.0 .SS "Gute Bibliotheksverwaltung" .P Eine gut verwaltete Bibliothek hat die folgenden Eigenschaften: .IP \(bu 4 seine API ist stabil (\(:offentliche Symbole entfallen nie, nur neue \(:offentliche Symbole werden hinzugef\(:ugt) und inkompatible \(:Anderungen erfolgen nur, wenn sich der SONAME \(:andert, .IP \(bu 4 idealerweise verwendet sie Symbolversionierung, um ABI\-Stabilit\(:at trotz interner \(:Anderungen und API\-Erweiterungen zu erreichen, .IP \(bu 4 sie exportiert nie private Symbole (als Hilfsl\(:osung k\(:onnen diese als optional gekennzeichnet werden). .P Bei der Verwaltung der Symboldatei kann das Auftauchen und Verschwinden von Symbolen leicht bemerkt werden. Es ist aber schwieriger, inkompatbile API\- und ABI\-\(:Anderungen zu bemerken. Daher sollte der Betreuer intensiv die Changelog\-Eintr\(:age durchschauen und nach F\(:allen suchen, in denen die Regeln der guten Bibliotheksverwaltung gebrochen wurden. Falls m\(:ogliche Probleme entdeckt wurden, sollten der Originalautor informiert werden, da eine Korrektur vom Originalautor immer besser als eine Debian\-spezifische Hilfsl\(:osung ist. .SH OPTIONEN .TP \fB\-P\fP\fIPaketbauverzeichnis\fP Suche nach \fIPaketbauverzeichnis\fP statt nach debian/tmp. .TP \fB\-p\fP\fIPaket\fP Definiert den Paketnamen. Ben\(:otigt, falls mehr als ein bin\(:ares Paket in debian/control aufgef\(:uhrt ist (oder falls es keine Datei debian/control gibt). .TP \fB\-v\fP\fIVersion\fP Definiert die Paketversion. Standardm\(:a\(ssig wird die Version aus debian/changelog entnommen. Ben\(:otigt, falls der Aufruf au\(sserhalb des Quellpaketbaums erfolgt. .TP \fB\-e\fP\fIBibliotheksdatei\fP Nur die explizit aufgef\(:uhrten Bibliotheken untersuchen statt alle \(:offentlichen Bibliotheken zu finden. Sie k\(:onnen Shell\-Muster, die zur Expansion von Pfadnamen verwandt werden (siehe die Handbuchseite \fBFile::Glob\fP(3perl) f\(:ur weitere Details) in \fIBibliotheksdatei\fP verwenden, um mehrere Bibliotheken mit einem einzelnen Argument zu passen (andernfalls ben\(:otigen Sie mehrere \fB\-e\fP). .TP \fB\-l\fP\fIVerzeichnis\fP Stellt \fIVerzeichnis\fP der Liste der zu durchsuchenden privaten Laufzeitbibliotheken voran (seit Dpkg 1.19.1). Diese Option kann mehrfach angegeben werden. Hinweis: Verwenden Sie diese Variable, statt \fBLD_LIBRARY_PATH\fP 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\-\(:Ubersetzen problematisch werden. .TP \fB\-I\fP\fIDateiname\fP Verwende \fIDateiname\fP als Referenzdatei, um die Symboldatei zu erstellen, die dann im Paket selbst integriert wird. .TP \fB\-O\fP[\fIDateiname\fP] Die erstellte Symbols\-Datei auf die Standardausgabe oder nach \fIDateiname\fP, falls angegeben, ausgeben statt in \fBdebian/tmp/DEBIAN/symbols\fP (oder \fIPaket\-Bauverzeichnis\fP\fB/DEBIAN/symbols\fP falls \fB\-P\fP verwandt wurde). Falls \fIDateiname\fP bereits existiert, wird deren Inhalt als Grundlage f\(:ur die erstellte Symboldatei verwandt. Sie k\(:onnen diese Funktionalit\(:at benutzen, um eine Symboldatei zu aktualisieren, so dass sie zu einer neueren Version der Originalautoren Ihrer Bibliothek passt. .TP \fB\-t\fP Schreibe die Symboldatei im Vorlagenmodus statt im zu \fBdeb\-symbols\fP(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\(:atsmodus. Desweiteren k\(:onnten einige Symbole beim Schreiben einer Standard \fBdeb\-symbols\fP(5)\-Datei entfernt werden (gem\(:a\(ss der Verarbeitungsregeln f\(:ur Kennzeichen), w\(:ahrend in der Symboldateivorlage immer alle Symbole geschrieben werden. .TP \fB\-c\fP\fI[0\-4]\fP Definiert die Pr\(:ufungen, die beim Vergleich der erstellten Symboldatei mit der Vorlagendatei als Startpunkt erfolgen sollen. Standardstufe ist 1. Zunehmende Stufen f\(:uhren mehr Pr\(:ufungen durch und enthalten alle Pr\(:ufungen der niedrigeren Stufen. Stufe 0 schl\(:agt nie fehl. Stufe 1 schl\(:agt fehl, wenn einige Symbole verschwunden sind. Stufe 2 schl\(:agt fehlt, falls einige neue Symbole eingef\(:uhrt wurden. Stufe 3 schl\(:agt fehl, falls einige Bibliotheken verschwunden sind. Stufe 4 schl\(:agt fehl, falls einige Bibliotheken hinzugekommen sind. Dieser Wert kann von der Umgebungsvariablen \fBDPKG_GENSYMBOLS_CHECK_LEVEL\fP au\(sser Kraft gesetzt werden. .TP \fB\-q\fP Ruhig verhalten und nie einen Diff zwischen der erstellten Symboldatei und der als Startpunkt verwandten Vorlagendatei erstellen oder keine Warnungen bez\(:uglich neuer/verlorender Bibliotheken oder neuer/verlorender Symbole ausgeben. Diese Option deaktiviert nur die informative Ausgabe aber nicht die Pr\(:ufungen selbst (sehen Sie hierzu die Option \fB\-c\fP). .TP \fB\-a\fP\fIArchitektur\fP Nehme \fIArch\fP als Host\-Architektur beim Verarbeiten der Symboldateien an. Verwenden Sie diese Option, um Symboldateien oder Diffs f\(:ur beliebige Architekturen zu erstellen, vorausgesetzt, die Bin\(:arprogramme sind bereits verf\(:ugbar. .TP \fB\-d\fP Debug\-Modus aktivieren. Eine Vielzahl von Nachrichten wird angezeigt, um zu erkl\(:aren, was \fBdpkg\-gensymbols\fP durchf\(:uhrt. .TP \fB\-V\fP Ausf\(:uhrlichen Modus aktivieren. Die erstellte Symboldatei enth\(:alt veraltete Symbole als Kommentare. Im Vorlagenmodus werden Mustersymbole desweiteren von Kommentaren gefolgt, die die echten Symbole auff\(:uhren, die auf dieses Muster passen. .TP \fB\-?\fP, \fB\-\-help\fP Zeige den Bedienungshinweis und beende. .TP \fB\-\-version\fP Gebe die Version aus und beende sich. . .SH UMGEBUNG .TP \fBDPKG_GENSYMBOLS_CHECK_LEVEL\fP Setzt die Befehls\(:uberpr\(:ufungsstufe au\(sser Kraft, selbst wenn das Befehlszeilenargument \fB\-c\fP \(:ubergeben wurde (beachten Sie, dass dies der \(:ublichen Konvention widerspricht, demnach Befehlszeilenargumente Vorrang \(:uber Umgebungsvariablen haben). .TP \fBDPKG_COLORS\fP Setzt den Farbmodus (seit Dpkg 1.18.5). Die derzeit unterst\(:utzten Werte sind: \fBauto\fP (Vorgabe), \fBalways\fP und \fBnever\fP. .TP \fBDPKG_NLS\fP Falls dies gesetzt ist, wird es zur Entscheidung, ob Native Language Support, auch als Internationalisierung (oder i18n) Unterst\(:utzung bekannt, aktiviert wird (seit Dpkg 1.19.0). Die akzeptierten Werte sind: \fB0\fP und \fB1\fP (Vorgabe). . .SH "SIEHE AUCH" \fBhttps://people.redhat.com/drepper/symbol\-versioning\fP .br \fBhttps://people.redhat.com/drepper/goodpractice.pdf\fP .br \fBhttps://people.redhat.com/drepper/dsohowto.pdf\fP .br \fBdeb\-symbols\fP(5), \fBdpkg\-shlibdeps\fP(1). .SH \(:UBERSETZUNG Die deutsche \(:Ubersetzung wurde 2004, 2006-2019 von Helge Kreutzmann , 2007 von Florian Rehnisch und 2008 von Sven Joachim angefertigt. Diese \(:Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 2 oder neuer f\(:ur die Kopierbedingungen. Es gibt KEINE HAFTUNG.