dpkg-gensymbols Man page

dpkg-gensymbols Utilitaires de dpkg dpkg-gensymbols

NOM
dpkg-gensymbols – création des fichiers de symboles (information desti‐
née aux dépendances de bibliothèques partagées)

SYNOPSIS

dpkg-gensymbols [option…]

DESCRIPTION

dpkg-gensymbols analyse un répertoire temporaire de construction (par
défaut debian/tmp), y recherche les bibliothèques et crée un fichier
symbols qui les décrit. Si ce fichier n’est pas vide, il est installé
dans le sous-répertoire DEBIAN du répertoire de construction afin de
pouvoir être inclus dans les informations de contrôle du paquet.

Lors de la création de ces fichiers, il utilise en entrée certains
fichiers de symboles fournis par le responsable. Il recherche les
fichiers suivants (en utilisant le premier trouvé) :

· debian/paquet.symbols.arch

· debian/symbols.arch

· debian/paquet.symbols

· debian/symbols

L’intérêt principal de ces fichiers est de fournir la version minimale
associée à chaque symbole fourni par les bibliothèques. En général,
cela correspond à la première version du paquet qui a fourni ce sym‐
bole, mais cette valeur peut être augmentée manuellement par le respon‐
sable si l’interface binaire applicative (ABI) du symbole est étendue
sans casser la compatibilité avec les versions précédentes. La tenue à
jour de ces fichiers est à la charge du responsable du paquet, avec
l’aide de dpkg-gensymbols.

Quand les fichiers de symboles créés sont différents de ceux fournis
par le responsable, dpkg-gensymbols affichera les différences entre les
deux fichiers. Si ces différences sont trop importantes, le programme
peut même se terminer en échec (le nombre de différences tolérées peut
être réglé avec l’option -c).

TENUE À JOUR DES FICHIERS SYMBOLES
The symbols files are really useful only if they reflect the evolution
of the package through several releases. Thus the maintainer has to
update them every time that a new symbol is added so that its associa‐
ted minimal version matches reality. The diffs contained in the build
logs can be used as a starting point, but the maintainer, additionally,
has to make sure that the behaviour of those symbols has not changed in
a way that would make anything using those symbols and linking against
the new version, stop working with the old version. In most cases, the
diff applies directly to the debian/package.symbols file. That said,
further tweaks are usually needed: it’s recommended for example to drop
the Debian revision from the minimal version so that backports with a
lower version number but the same upstream version still satisfy the
generated dependencies. If the Debian revision can’t be dropped because
the symbol really got added by the Debian specific change, then one
should suffix the version with ‘~’.

Avant d’appliquer le correctif au fichier de symboles, le responsable
doit contrôler qu’il est correct. Les symboles publics sont supposés ne
jamais disparaître et le correctif ne devrait donc qu’ajouter des
lignes.

Note that you can put comments in symbols files: any line with ‘#’ as
the first character is a comment except if it starts with ‘#include’
(see section Using includes). Lines starting with ‘#MISSING:’ are spe‐
cial comments documenting symbols that have disappeared.

N’oubliez pas de vérifier les anciennes versions des symboles ne
doivent pas être incrémentées. Il n’y a pas de moyen pour que dpkg-gen‐
symbols prévienne de cela. Appliquer aveuglement le fichier de diffé‐
rences ou supposer qu’il n’y a rien à changer, s’il n’y a pas de
fichier de différences, sans vérifier si il de telles modifications, ce
qui peut faire que des paquets, avec des dépendances lâches, prétendent
qu’ils peuvent fonctionner avec des paquets plus anciens avec lesquels
ils ne peuvent fonctionner. Cela introduira des bogues difficiles à
trouver avec des mises à jour (partielles).

Utilisation du remplacement de #PACKAGE#
Dans de rares cas, le nom de la bibliothèque dépend de l’architecture.
Afin d’éviter de coder le nom du paquet en dur dans le fichier de sym‐
boles, il est possible d’utiliser le marqueur #PACKAGE#. Il sera rem‐
placé par le vrai nom du paquet lors de l’installation des fichiers de
symboles. À la différence du marqueur #MINVER#, #PACKAGE# n’apparaîtra
jamais dans le fichier de symboles d’un paquet binaire.

Utilisation des étiquettes de symbole
L’étiquetage des symboles (« symbol tagging ») est utile pour marquer
des symboles qui sont particuliers d’une manière ou d’une autre. Tout
symbole peut avoir un nombre quelconque d’étiquettes associées. Bien
que toutes les étiquettes soient analysées et conservées, seules cer‐
taines d’entre elles sont comprises par dpkg-gensymbols et déclenchent
un traitement spécifique des symboles. Veuillez consulter la sous-sec‐
tion Étiquettes standard de symbole pour une référence complète à pro‐
pos de ces étiquettes.

L’indication de l’étiquette vient juste avant le nom du symbole (sans
espace). Elle commence toujours par une parenthèse ouvrante (, se ter‐
mine avec une parenthèse fermante ) et doit contenir au moins une éti‐
quette. Les étiquettes multiples doivent être séparées par le caractère
|. Chaque étiquette peut comporter optionnellement une valeur, séparée
du nom de l’étiquette par le caractère =. Les noms et valeurs des éti‐
quettes sont des chaînes quelconques qui ne doivent pas comporter les
caractères ) | et =. Les noms de symbole qui suivent une étiquette
peuvent optionnellement être mis entre guillemets avec les caractères ‘
ou ” afin d’y autoriser la présence d’espaces. Cependant, si aucune
étiquette n’est utilisée, les guillemets sont alors traités comme une
partie du nom du symbole, qui s’arrête alors au premier espace.

(étiq1=je suis marqué|étiquette avec espace)”symbole comportant des
espaces”@Base 1.0
(optional)symbole_non_protégé@Base 1.0 1
symbole_non_étiqueté@Base 1.0

Le premier symbole de cet exemple est appelé symbole comportant des
espaces et utilise deux étiquettes : étiq1 avec la valeur je suis mar‐
qué et étiquette avec espace sans valeur. Le deuxième symbole, appelé
symbole_non_protégé ne comporte que l’étiquette optional. Le dernier
symbole est un exemple de symbole normal sans étiquette.

Comme les étiquettes de symbole sont une extension du format de
deb-symbols(5), elles ne peuvent apparaître que dans les fichiers de
symboles des paquets source (ces fichiers peuvent ensuite être vus
comme des modèles permettant de construire les fichiers de symboles
inclus dans les paquets binaires). Lorsque dpkg-gensymbols est lancé
sans l’option -t, il affiche les fichiers de symboles compatibles avec
le format deb-symbols(5) : il traite entièrement les symboles d’après
les exigences des étiquettes standard et supprime les étiquettes dans
sa sortie. Au contraire, dans le mode modèle (« template », option -t),
tous les symboles et leurs étiquettes (standard et inconnues) sont
conservés dans la sortie et écrits dans leur forme d’origine.

Étiquettes standard de symbole
optional
A symbol marked as optional can disappear from the library at
any time and that will never cause dpkg-gensymbols to fail.
However, disappeared optional symbols will continuously appear
as MISSING in the diff in each new package revision. This beha‐
viour serves as a reminder for the maintainer that such a symbol
needs to be removed from the symbol file or readded to the
library. When the optional symbol, which was previously declared
as MISSING, suddenly reappears in the next revision, it will be
upgraded back to the “existing” status with its minimum version
unchanged.

Cette étiquette est utile pour les symboles qui sont privés car
leur disparition ne provoque pas de changement d’interface
applicative (ABI). Par exemple, la plupart des modèles d’instan‐
ciation C++ sont dans cette catégorie. Comme toute autre éti‐
quette, celle-ci peut comporter une valeur arbitraire qui peut
servir à indiquer pour quelle raison le symbole est optionnel.

arch=architecture-list
arch-bits=architecture-bits
arch-endian=architecture-endianness
These tags allow one to restrict the set of architectures where
the symbol is supposed to exist. The arch-bits and arch-endian
tags are supported since dpkg 1.18.0. 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 sup‐
posed 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.

Dans le mode de fonctionnement par défaut (pas en mode
« modèle »), seuls les symboles spécifiques de certaines archi‐
tectures qui correspondent à l’architecture courante sont écrits
dans le fichier de symboles. Au contraire, tous les symboles
spécifiques d’architectures (y compris ceux des architectures
différentes) seront écrits dans le fichier de symboles, dans le
mode « modèle ».

The format of architecture-list is the same as the one used in
the Build-Depends field of debian/control (except the enclosing
square brackets []). For example, the first symbol from the list
below will be considered only on alpha, any-amd64 and ia64
architectures, the second only on linux architectures, while the
third one anywhere except on armel.

(arch=alpha any-amd64 ia64)un_symbole_spécifique_64bit@Base 1.0
(arch=linux-any)un_symbole_spécifique_linux@Base 1.0
(arch=!armel)un_symbole_inexistant_sur_armel@Base 1.0

The architecture-bits is either 32 or 64.

(arch-bits=32)a_32bit_specific_symbol@Base 1.0
(arch-bits=64)a_64bit_specific_symbol@Base 1.0

The architecture-endianness is either little or big.

(arch-endian=little)a_little_endian_specific_symbol@Base 1.0
(arch-endian=big)a_big_endian_specific_symbol@Base 1.0

Multiple restrictions can be chained.

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

ignore-blacklist
dpkg-gensymbols comporte une liste interne de symboles ignorés
qui ne devraient pas apparaître dans les fichiers de symboles
car ils sont en général uniquement des effets de bord de détails
de mise en ?uvre de la chaîne d’outils de construction. Si, pour
une raison précise, vous voulez vraiment inclure un de ces sym‐
boles dans le fichier, vous pouvez imposer qu’il soit ignoré,
avec ignore-blacklist. Cela peut être utile pour certaines
bibliothèques de bas niveau telles que libgcc.

c++ Indique un motif de symbole c++. Voir la sous-section Utilisa‐
tion de motifs de symbole plus loin.

symver Indique un motif de symbole symver (version de symbole). Voir la
sous-section Utilisation des motifs de symboles plus loin.

regex Indique un motif de symbole basé sur des expressions ration‐
nelles. Voir la sous-section Utilisation des motifs de symboles
plus loin.

Utilisation des motifs de symboles
Au contraire d’une indication normale de symbole, un motif permet de
couvrir des symboles multiples de la bibliothèque. dpkg-gensymbols
essaie de faire correspondre chaque motif à chaque symbole qui n’est
pas explicitement défini dans le fichier de symboles. Dès qu’un motif
est trouvé qui correspond au symbole, l’ensemble de ses étiquettes et
propriétés sont utilisées comme spécification de base du symbole. Si
aucun des motifs ne correspond, le symbole sera considéré comme nou‐
veau.

Un motif est considéré comme perdu si aucun symbole ne lui correspond
dans la bibliothèque. Par défaut, cela provoquera un échec de dpkg-gen‐
symbols s’il est utilisé avec l’option -c1 (ou une valeur plus élevée).
Cependant, si l’échec n’est pas souhaité, le motif peut être marqué
comme optionnel avec l’étiquette optional. Dans ce cas, si le motif ne
correspond à rien, il sera simplement mentionné dans le fichier de dif‐
férences comme MISSING (manquant). De plus, comme pour tout autre sym‐
bole, le motif peut être limité à des architectures données avec l’éti‐
quette arch. Veuillez consulter la sous-section Étiquettes standard de
symbole pour plus d’informations.

Les motifs sont une extension du format de deb-symbols(5) en ce sens
qu’ils ne sont valables que dans les modèles de fichiers de symboles.
Cependant, la partie comportant le nom de symbole est utilisée comme
une expression à faire correspondre à name@version du symbole réel.
Afin de faire la distinction entre les différents types de motifs, un
motif sera usuellement marqué avec une étiquette spéciale.

Actuellement, dpkg-gensymbols gère trois types de base de motifs :

c++
Ce motif est repéré par l’étiquette c++. Il ne sera comparé qu’aux
symboles C++ avec leur nom de symbole complet (demangled) tel
qu’affiché avec l’utilitaire c++filt. Ce motif est très pratique
pour faire correspondre les symboles dont les noms raccourcis (man‐
gled) peuvent différer selon les architectures bien que leurs noms
complets restent les mêmes. Un tel groupe de symboles sont les
non-virtual thunks pour lesquels les décalages (offsets) spécifiques
d’architectures sont inclus dans leur nom court. Une manifestation
usuelle de ce cas est le destructeur virtuel qui, dans le contexte
d’un « problème du diamant », a besoin d’un symbole de transition
spécial (ou « thunk ») non virtuel. Par exemple, même si
_ZThn8_N3NSB6ClassDD1Ev@Base sur une architecture 32 bits est iden‐
tique à _ZThn16_N3NSB6ClassDD1Ev@Base sur une architecture 64 bits,
les deux peuvent être indiqués avec le même motif c++ :

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

Le nom complet ci-dessus peut être obtenu avec la commande sui‐
vante :

$ echo ‘_ZThn8_N3NSB6ClassDD1Ev@Base’ | c++filt

Veuillez noter que, bien que le nom complet soit unique dans la
bibliothèque par définition, cela n’est pas forcément vrai pour le
nom raccourci. Deux symboles réels différents peuvent avoir le même
nom raccourci. C’est par exemple le cas avec les symboles « thunk »
non virtuels dans des configurations d’héritage complexes ou avec la
plupart des constructeurs et destructeurs (puisque g++ crée usuelle‐
ment deux symboles réels pour eux). Cependant, comme ces collisions
se produisent au niveau de l’interface applicative binaire (ABI),
elles ne devraient pas dégrader la qualité du fichier de symboles.

symver
Ce motif est indiqué par l’étiquette symver. Les bibliothèques bien
gérées utilisent des symboles versionnés où chaque version corres‐
pond à la version amont à laquelle le symbole a été ajouté. Si c’est
le cas, il est possible d’utiliser un motif symver pour faire cor‐
respondre chaque symbole associé à la version spécifique. Par
exemple :

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

Tous les symboles associés avec les versions GLIBC_2.0 et GLIBC_2.7
conduiront respectivement à des versions minimales de 2.0 et 2.7, à
l’exception du symbole access@GLIBC_2.0. Ce dernier amène à une
dépendance minimale sur la version 2.2 de libc6 bien qu’il soit dans
le scope de « (symvar)GLIBC_2.0 ». Cela est dû au fait que les sym‐
boles spécifiques prennent le pas sur les motifs.

Veuillez noter que les anciens motifs avec caractères génériques
(indiqués sous la forme « *@version ») dans le champ de nom de sym‐
bole sont toujours gérés. La nouvelle syntaxe « (symver|optio‐
nal)version » doit toutefois leur être préférée. Par exemple,
« *@GLIBC_2.0 2.0 » devrait être écrit sous la forme « (sym‐
ver|optional)GLIBC_2.0 2.0 » si un comportement analogue est recher‐
ché.

regex
Les motifs d’expressions rationnelles sont indiqués par l’étiquette
regex. La correspondance se fait avec une expression rationnelle
Perl sur le champ de nom de symbole. La correspondance est faite
telle quelle et il ne faut donc pas oublier le caractère ^, sinon la
correspondance est faite sur n’importe quelle partie du symbole réel
name@version. Par exemple :

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

Les symboles tels que « mystack_new@Base », « mystack_push@Base »,
« mystack_pop@Base », etc. seront en correspondance avec le premier
motif alors que, par exemple, « ng_mystack_new@Base » ne le sera
pas. Le deuxième motif correspondra pour tous les symboles qui com‐
portent la chaîne « private » dans leur nom et les correspondances
hériteront de l’étiquette optional depuis le motif.

Les motifs de base indiqués précédemment peuvent être combinés au
besoin. Dans ce cas, ils sont traités dans l’ordre où les étiquettes
sont indiquées. Par exemple, les deux motifs

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

Seront en correspondance avec les symboles « _ZN3NSA6ClassA7Pri‐
vate11privmethod1Ei@Base” » et « _ZN3NSA6ClassA7Private11privme‐
thod2Ei@Base ». Lors de la correspondance avec le premier motif, le
symbole complet est d’abord décodé en tant que symbole C++, puis com‐
paré à l’expression rationnelle. D’un autre côté, lors de la correspon‐
dance avec le deuxième motif, l’expression rationnelle est comparée au
nom de symbole brut, puis le symbole est testé en tant que symbole C++
en tentant de le décoder. L’échec de n’importe quel motif de base pro‐
voquera l’échec de l’ensemble du motif. Ainsi, par exemple,
« __N3NSA6ClassA7Private11privmethod\dEi@Base » ne correspondra à aucun
des motifs car ce n’est pas un symbole C++ valable (NdT : j’ai
l’impression de traduire du Klingon !).

En général, les motifs sont divisés en deux groupes : les alias (c++ et
symver de base) et les motifs génériques (regex et toutes les combinai‐
sons de motifs de base multiples). La correspondance de motifs basés
sur des alias est rapide (O(1)) alors que les motifs génériques sont
O(N) (N étant le nombre de motifs génériques) pour chaque symbole. En
conséquence, il est déconseillé d’abuser des motifs génériques.

Lorsque plusieurs motifs correspondent pour le même symbole réel, les
alias (d’abord c++, puis symver) sont privilégiés par rapport aux
motifs génériques. Ceux-ci sont essayés dans l’ordre où ils appa‐
raissent dans le modèle de fichier de symboles, en s’arrêtant à la pre‐
mière correspondance. Veuillez noter, cependant, que la modification
manuelle de l’ordre des entrées de fichiers n’est pas recommandée car
dpkg-gensymbols crée des fichiers de différences d’après l’ordre alpha‐
numérique de leur nom.

Utilisation des inclusions
Lorsqu’un jeu de symboles exportés varie selon les architectures, il
est souvent peu efficace d’utiliser un seul fichier de symboles. Pour
couvrir ces cas, une directive d’inclusion peut devenir utile dans cer‐
tains cas :

· Il est possible de factoriser la partie commune dans un fichier
externe donné et l’inclure dans le fichier paquet.symbols.arch avec
une directive « include » utilisée de la manière suivante :

#include “paquets.symbols.common”

· La directive d’inclusion peut également être étiquetée comme tout
autre symbole :

(étiquette|…|étiquetteN)#include “fichier_à_inclure”

Le résultat sera que tous les symboles inclus depuis
fichier_à_inclure seront considérés comme étiquetés par défaut avec
etiq … etiqN. Cela permet de créer un fichier paquet.symbols com‐
mun qui inclut les fichiers de symboles spécifiques des architec‐
tures :

symbole_commun1@Base 1.0
(arch=amd64 ia64 alpha)#include “package.symbols.64bit”
(arch=!amd64 !ia64 !alpha)#include “package.symbols.32bit”
symbole_commun2@Base 1.0

Les fichiers de symboles sont lus ligne par ligne et les directives
d’inclusion sont traitées dès qu’elles sont trouvées. En conséquence,
le contenu du fichier d’inclusion peut remplacer une définition qui
précède l’inclusion et ce qui suit l’inclusion peut remplacer une défi‐
nition qu’elle ajoutait. Tout symbole (ou même une autre directive
d’inclusion) dans le fichier inclus peut définir des étiquettes supplé‐
mentaires ou remplacer les valeurs d’étiquettes héritées, dans sa défi‐
nition d’étiquettes. Cependant, pour un symbole donné, il n’existe pas
de méthode permettant de remplacer une de ses étiquettes héritées.

Un fichier inclus peut reprendre la ligne d’en-tête qui contient le
« SONAME » de la bibliothèque. Dans ce cas, cela remplace toute ligne
d’en-tête précédente. Il est cependant déconseillé de dupliquer les
lignes d’en-tête. Une façon de le faire est la méthode suivante :

#include “libmachin1.symbols.common”
symboles_specifique_architecture@Base 1.0

Bonnes pratiques de gestion des bibliothèques
Une bibliothèque bien maintenue offre les possibilités suivantes :

· son interface de programmation (API) est stable (les symboles
publics ne sont jamais supprimés et les changements ne concernent
que des ajouts de nouveaux symboles publics) et les modifications
provoquant une incompatibilité doivent être combinés avec un chan‐
gement de SONAME ;

· idéalement, elle utilise le versionnement des symboles pour garan‐
tir la stabilité de l’interface applicative binaire (ABI) malgré
ses modifications internes et l’extension de son API ;

· elle n’exporte pas les symboles privés (afin de contourner cela, de
tels symboles peuvent être étiquetés comme optionnels).

En maintenant le fichier de symboles, il est facile d’en voir appa‐
raître et disparaître. Cependant, il est plus difficile de contrôler la
présence d’éventuelles modifications d’API ou ABI. En conséquence, le
responsable doit contrôler soigneusement le journal des modifications
amont, à la recherche de cas où une saine gestion des bibliothèques
peut avoir été omise. Si des problèmes potentiels sont découverts,
l’auteur amont doit être averti(e) car une correction en amont est
meilleure qu’un travail spécifique au paquet Debian.

OPTIONS

-Prépertoire-construction-paquet
Analyse de répertoire-construction-paquet, plutôt que
debian/tmp.

-ppaquet
Définit le nom du paquet. Requis si plus d’un paquet binaire est
indiqué dans debian/control (ou s’il n’y a pas de fichier
debian/control).

-vversion
Définit la version du paquet. La valeur par défaut est la ver‐
sion extraite de debian/changelog. Ce paramètre est requis si le
programme est lancé en dehors de l’arborescence source d’un
paquet.

-efichier-bibliothèque
N’analyse que les bibliothèques explicitement mentionnées au
lieu de rechercher toutes les bibliothèques publiques. Les
motifs du shell peuvent être utilisés pour l’expansion des che‐
mins d’accès (voir la page de manuel de File::Glob(3perl) pour
plus d’informations) dans fichier-bibliothèque pour établir une
correspondance avec plusieurs bibliothèques avec un seul
paramètre (afin d’éviter d’utiliser plusieurs options -e).

-Inom-de-fichier
Utilise nom-de-fichier comme fichier de référence pour créer le
fichier de symboles à intégrer dans le paquet lui-même.

-O[nom-de-fichier] Affiche le fichier de symboles créé sur la sortie standard ou
dans le nom-de-fichier, si spécifié, plutôt que dans
debian/tmp/DEBIAN/symbols (ou répertoire-construc‐
tion-paquet/DEBIAN/symbols si -P est présent). Si nom-de-fichier
existe déjà, son contenu sera utilisé comme base pour le fichier
créé. Cette fonctionnalité permet de mettre à jour le fichier de
symboles pour qu’il corresponde à une nouvelle version amont de
la bibliothèque.

-t Écrit le fichier de symboles en mode modèle plutôt que dans un
format compatible avec deb-symbols(5). La différence majeure
réside dans le fait que les noms de symboles et les étiquettes
sont écrits dans leur forme d’origine au lieu d’être interpré‐
tés, avec réduction des étiquettes en mode de compatibilité. De
plus, certains symboles peuvent être omis lors de l’écriture
d’un fichier deb-symbols(5) standard (selon les règles de trai‐
tement des étiquettes) alors que tous les symboles sont écrits
lors de la création d’un modèle de fichier de symboles.

-c[0-4] Définit les contrôles à effectuer lors de la comparaison des
symboles créés en utilisant le fichier de modèle comme point de
départ. Le niveau par défaut est 1. Plus le niveau est augmenté,
plus le nombre de contrôles effectués est important. Chaque
niveau de contrôle comporte les contrôles effectués pour les
niveaux inférieurs. Le niveau 0 n’échoue jamais. Le niveau 1
échoue si certains symboles ont disparu. Le niveau 2 échoue si
de nouveaux symboles ont été ajoutés. Le niveau 3 échoue si cer‐
taines bibliothèques ont disparu. Le niveau 4 échoue si des
bibliothèques ont été ajoutées.

Cette valeur peut être remplacée par la valeur de la variable
d’environnement DPKG_GENSYMBOLS_CHECK_LEVEL.

-q Fonctionne en mode silencieux et ne crée jamais de fichier de
différences entre le fichier de symboles créé et le fichier
modèle utilisé comme point de départ. N’affiche également aucun
avertissement à propos de bibliothèques nouvelles ou disparues
ou de symboles nouveaux ou disparus. Cette option ne désactive
que l’affichage informatif, mais pas les contrôles eux-mêmes
(voir l’option -c).

-aarch Définit arch comme architecture lors du traitement des fichiers
de symboles. Cette option permet de créer un fichier de symboles
ou un fichier de différences pour n’importe quelle architecture,
à condition que les fichiers binaires correspondants soient déjà
disponibles.

-d Active le mode bavard. De nombreux messages sont affichés pour
expliquer ce que dpkg-gensymbols fait.

-V Active le mode bavard. Le fichier de symboles créé contiendra
les symboles dépréciés sous forme de commentaires. De plus, en
mode modèle, les motifs de symboles seront suivis de commen‐
taires affichant les symboles réels qui correspondent au motif.

-?, –help
Affiche un message d’aide puis quitte.

–version
Affiche le numéro de version puis quitte.

VOIR AUSSI
https://people.redhat.com/drepper/symbol-versioning
https://people.redhat.com/drepper/goodpractice.pdf
https://people.redhat.com/drepper/dsohowto.pdf
deb-symbols(5), dpkg-shlibdeps.

TRADUCTION
Ariel VARDI , 2002. Philippe Batailler, 2006.
Nicolas François, 2006. Veuillez signaler toute erreur à
.

Projet Debian 2014-12-29 dpkg-gensymbols