path: root/man/de/deb-src-symbols.pod

        *****************************************************
        *           GENERATED FILE, DO NOT EDIT             *
        * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
        *****************************************************

This file was generated by po4a(7). Do not store it (in VCS, for example),
but store the PO file used as source file by po4a-translate.

In fact, consider this as a binary, and the PO file as a regular .c file:
If the PO get lost, keeping this translation up-to-date will be harder.

=encoding UTF-8

=head1 BEZEICHNUNG

deb-symbols - Debians erweiterte Vorlagendatei für Laufzeitbibliotheken

=head1 ÜBERSICHT

B<debian/>I<Paket>B<.symbols.>I<Arch>, B<debian/symbols.>I<Arch>,
B<debian/>I<Paket>B<.symbols>, B<debian/symbols>

=head1 BESCHREIBUNG

Die Symboldateivorlagen werden in Debian-Quellpaketen ausgeliefert. Deren
Format ist eine Obermenge der in Binärpaketen ausgelieferten Symboldateien,
siehe L<deb-symbols(5)>.

=head2 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 B<Includes verwenden>). Zeilen, die mit ‚#MISSING:’
anfangen, sind besondere Kommentare, die verschwundene Symbole
dokumentieren.

=head2 Verwendung der #PACKAGE#-Ersetzung

In einigen seltenen Fällen sind die Namen der Bibliotheken nicht auf allen
Architekturen gleich. Um zu vermeiden, dass der Paketname in der Symboldatei
fest kodiert wird, können Sie die Markierung I<#PACKAGE#> verwenden. Während
der Installation der Symboldatei wird sie durch den echten Paketnamen
ersetzt. Anders als die Markierung I<#MINVER#> wird I<#PACKAGE#> nie in der
Symboldatei innerhalb eines Binärpakets auftauchen.

=head2 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 B<dpkg-gensymbols>
verstanden und lösen eine Spezialbehandlung der Symbole aus. Lesen Sie den
Unterabschnitt B<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 B<(>, enden mit einer schließenden Klammer B<)> und müssen
mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden
durch das Zeichen B<|> getrennt. Jede der Kennzeichnungen kann optional
einen Wert enthalten, der von der Kennzeichnung durch das Zeichen B<=>
getrennt wird. Kennzeichennamen und -werte können beliebige Zeichenketten
sein, sie dürfen allerdings keine der der besonderen Zeichen B<)> B<|> B<=>
enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, können
optional mit den Zeichen B<'> oder B<"> 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 B<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 B<dpkg-gensymbols>
ohne die Option B<-t> aufgerufen wird, wird es alle Symbole ausgeben, die
zum Format B<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 (B<-t>) in der Ausgabe beibehalten und in
ihrer Originalform, wie sie geladen wurden, auch geschrieben.

=head2 Standard-Symbolkennzeichnungen

=over 

=item B<optional>

Ein als „optional“ gekennzeichnetes Symbol kann jederzeit von der Bibliothek
verschwinden und wird nie zum Fehlschlag von B<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.

=item B<arch=>I<Architekturliste>

=item B<arch-bits=>I<Architektur-Bits>

=item B<arch-endian=>I<Architektur-Bytereihenfolge>

Diese Markierungen erlauben es, den Satz an Architekturen einzugrenzen, auf
denen das Symbol existieren sollte. Die Markierungen B<arch-bits> und
B<arch-endian> 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> 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 Bytereihenfolge und Bits
passt), wird sie architekturneutral gemacht (d.h. die Architektur-,
Architektur-Bits- und Architektur-Bytereihenfolgemarkierungen werden
entfernt und das Symbol wird im Diff aufgrund dieser Änderung auftauchen),
aber es wird nicht als neu betrachtet.

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 I<Architekturliste> ist das gleiche wie das des Feldes
B<Build-Depends> in I<debian/control> (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 auf Linux-Architekturen, während das dritte überall außer auf Armel
betrachtet wird.

  (arch=alpha any-amd64 ia64)64_Bit_spezifisches_Symbol@Base 1.0
  (arch=linux-any)Linux_spezifisches_Symbol@Base 1.0
  (arch=!armel)Symbol_das_Armel_nicht_hat@Base 1.0

I<Architektur-Bits> ist entweder B<32> oder B<64>.

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

I<Architektur-Bytereihenfolge> ist entweder B<little> oder B<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

=item B<allow-internal>

dpkg-gensymbols verfügt über eine interne Liste von Symbolen, die nicht in
Symboldateien auftauchen sollten, da sie normalerweise nur Nebeneffekte von
Implementierungsdetails in der Werkzeugkette darstellen (seit Dpkg
1.20.1). Falls Sie aus irgendeinem Grund wollen, dass diese Symbole in der
Symboldatei aufgenommen werden, sollten Sie das Symbol mit B<allow-internal>
kennzeichnen. Dies kann für einige grundlegende Bibliotheken der
Werkzeugkette wie „libgcc“ notwendig sein.

=item B<ignore-blacklist>

Ein veralteter Alias für B<allow-internal> (seit Dpkg 1.20.1, unterstützt
seit Dpkg 1.15.3).

=item B<c++>

Gibt I<c++>-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt
B<Verwendung von Symbolmustern>.

=item B<symver>

Gibt I<symver> (Symbolversion)-Symbolmuster an. Lesen Sie den nachfolgenden
Unterabschnitt B<Verwendung von Symbolmustern>.

=item B<regex>

Gibt I<regex>-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt
B<Verwendung von Symbolmustern>.

=back

=head2 Verwendung von Symbolmustern

Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale
Symbole aus der Bibliothek abdecken. B<dpkg-gensymbols> wird versuchen,
jedes Muster auf jedes reale Symbol, für das I<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.

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> in der Stufe B<-c1> oder höher auslösen. Falls der
Fehlschlag allerdings unerwünscht ist, kann das Muster mit der Kennzeichnung
I<optional> 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>
beschränkt werden. Bitte lesen Sie den Unterabschnitt
B<Standard-Symbolkennzeichnungen> oben für weitere Informationen.

Muster sind eine Erweiterung des Formats B<deb-symbols>(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<Name@Version> eines realen Symbols abgeglichen wird. Um zwischen den
verschiedenen Mustertypen zu unterscheiden, wird es typischerweise mit einer
speziellen Kennzeichnung gekennzeichnet.

Derzeit unterstützt B<dpkg-gensymbols> drei grundlegene Mustertypen:

=over 

=item B<c++>

Dieses Muster wird durch die Kennzeichnung I<c++> verzeichnet. Es passt nur
auf die entworrenen („demangled“) Symbolnamen (wie sie vom Hilfswerkzeug
B<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 I<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 I<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

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.

=item B<symver>

Dieses Muster wird durch die Kennzeichnung I<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 I<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.

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.

=item B<regex>

Muster mit regulären Ausdrücken werden durch die Kennzeichnung I<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 I<^> zu beginnen,
da er ansonsten auf jeden Teil der Zeichenkette des realen Symbols
I<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 z.B. 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 I<optional> vom Muster.

=back

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 I<c++>- und I<symver>-Muster) und generische Muster (I<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.

Wenn mehrere Muster auf das gleiche Symbol passen, werden Aliase (zuerst
I<c++>, dann I<symver>) gegenüber den generischen Mustern
bevorzugt. Generische Muster werden in der Reihenfolge, in der sie in der
Symboldateivorlage gefunden werden, verglichen, bis zum ersten
Erfolg. Beachten Sie aber, dass das manuelle Anordnen der
Vorlagendateieinträge nicht empfohlen wird, da B<dpkg-gensymbols> Diffs
basierend auf der alphanumerischen Reihenfolge ihrer Namen erstellt.

=head2 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:

=over 

=item *

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

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

=item *

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

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

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

  gemeinsames_Symbol1@Base 1.0
 (arch=amd64 ia64 alpha)#include "Paket.symbols.64bit"
 (arch=!amd64 !ia64 !alpha)#include "Paket.symbols.32bit"
  gemeinsames_Symbol2@Base 1.0

=back

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

=head1 SIEHE AUCH

B<deb-symbols>(5), B<dpkg-shlibdeps>(1), B<dpkg-gensymbols>(1).


=head1 ÜBERSETZUNG

Die deutsche Übersetzung wurde 2004, 2006-2020 von Helge Kreutzmann
<debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de> und
2008 von Sven Joachim <svenjoac@gmx.de>
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.