649 lines
34 KiB
HTML
649 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-suite (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>NAAM</H2>
|
|
|
|
dpkg-gensymbols - genereer symbolenbestanden (informatie over
|
|
afhankelijkheidsrelaties met gedeelde bibliotheken)
|
|
<A NAME="lbAC"> </A>
|
|
<H2>OVERZICHT</H2>
|
|
|
|
<B>dpkg-gensymbols</B> [<I>optie</I>...]
|
|
<A NAME="lbAD"> </A>
|
|
<H2>BESCHRIJVING</H2>
|
|
|
|
<B>dpkg-gensymbols</B> doorzoekt een tijdelijke bouwboom (standaard is dat
|
|
debian/tmp) op zoek naar bibliotheken en genereert een <I>symbols</I>-bestand
|
|
dat ze beschrijft. Dit bestand wordt dan als het niet leeg is, geïnstalleerd
|
|
in een onderliggende map van de bouwboom met de naam DEBIAN, zodat het
|
|
uiteindelijk opgenomen geraakt in de controle-informatie van het pakket.
|
|
<P>
|
|
|
|
Bij het genereren van deze bestanden gebruikt het als invoer bepaalde
|
|
symbolenbestanden die door de onderhouder aangeleverd worden. Het zoekt naar
|
|
de volgende bestanden (en gebruikt het eerste dat gevonden wordt):
|
|
<DL COMPACT>
|
|
<DT id="1">•<DD>
|
|
debian/<I>pakket</I>.symbols.<I>arch</I>
|
|
<DT id="2">•<DD>
|
|
debian/symbols.<I>arch</I>
|
|
<DT id="3">•<DD>
|
|
debian/<I>pakket</I>.symbols
|
|
<DT id="4">•<DD>
|
|
debian/symbols
|
|
</DL>
|
|
<P>
|
|
|
|
Het hoofddoel van deze bestanden is aan te geven welke de minimale versie is
|
|
die behoort bij elk van de symbolen die door de bibliotheken aangeleverd
|
|
worden. Gewoonlijk komt dit overeen met de eerste versie van het pakket dat
|
|
in dat symbool voorzag, maar dit kan door de onderhouder manueel verhoogd
|
|
worden indien de ABI van het symbool uitgebreid werd zonder dat daardoor de
|
|
neerwaartse compatibiliteit verbroken wordt. Het is de verantwoordelijkheid
|
|
van de onderhouder om deze bestanden up-to-date en accuraat te houden, maar
|
|
<B>dpkg-gensymbols</B> helpt hierbij.
|
|
<P>
|
|
|
|
Indien het gegenereerde symbolenbestand verschilt van datgene wat de
|
|
onderhouder aanlevert, zal <B>dpkg-gensymbols</B> de verschillen tussen de twee
|
|
versies tonen in diff-formaat. Bovendien kan dit zelfs tot een mislukking
|
|
leiden als de verschillen te significant zijn (u kunt aanpassen hoeveel
|
|
verschil u kunt tolereren; zie de optie <B>-c</B>).
|
|
<A NAME="lbAE"> </A>
|
|
<H2>HET ONDERHOUD VAN SYMBOLENBESTANDEN</H2>
|
|
|
|
De symbolenbestanden zijn pas echt nuttig als ze de evolutie van het pakket
|
|
reflecteren doorheen verschillende releases. De onderhouder moet ze dus
|
|
iedere keer bijwerken wanneer een nieuw symbool toegevoegd wordt, zodat de
|
|
minimale versie die eraan gekoppeld wordt, overeenkomt met de realiteit. De
|
|
diffs (weergave van de verschillen) die in de bouwlogs te vinden zijn,
|
|
kunnen als startpunt genomen worden, maar daarbovenop moet de onderhouder
|
|
erop letten dat het gedrag van deze symbolen niet zodanig veranderd werd,
|
|
dat iets dat van deze symbolen gebruik maakt en linkt met de nieuwe versie,
|
|
niet stopt met werken met de oude versie. In de meeste gevallen kan de diff
|
|
rechtstreeks toegepast worden op het bestand debian/<I>pakket</I>.symbols. Dit
|
|
gezegd zijnde, zijn verdere aanpassingen meestal wel nodig: het wordt
|
|
bijvoorbeeld aanbevolen om het Debian revisienummer weg te laten uit de
|
|
minimale versie, zodat backports (nieuwere programmaversies die geschikt
|
|
gemaakt worden voor een vroegere release) met een lager versienummer maar
|
|
eenzelfde toeleveraarsversie (upstream version) nog steeds voldoen aan de
|
|
gegenereerde afhankelijkheidsrelaties. Indien het Debian revisienummer niet
|
|
weggelaten kan worden omdat het symbool echt via een Debian-specifieke
|
|
aanpassing toegevoegd werd, moet men aan het versienummer het achtervoegsel
|
|
'<B>~</B>' toevoegen.
|
|
<P>
|
|
|
|
Vooraleer een patch toe te passen op een symbolenbestand, moet de
|
|
onderhouder grondig controleren of dat wel correct is. Publieke symbolen
|
|
worden verondersteld niet te verdwijnen. Een patch zou dus idealiter enkel
|
|
nieuwe regels mogen toevoegen.
|
|
<P>
|
|
|
|
Merk op dat u commentaar kunt opnemen in symbolenbestanden: elke regel met
|
|
'#' als eerste teken is een commentaarregel, behalve als die regel begint
|
|
met '#include' (zie het onderdeel over <B>Het gebruik van includes</B>). Regels
|
|
die beginnen met '#MISSING:' zijn een bijzondere vorm van commentaar waarin
|
|
symbolen die verdwenen zijn, gedocumenteerd worden.
|
|
<P>
|
|
|
|
Vergeet niet na te gaan of oudere symboolversies niet verhoogd moeten
|
|
worden. Er bestaat geen manier voor <B>dpkg-gensymbols</B> om in dit verband
|
|
waarschuwingen te geven. Een diff (weergave van de verschillen) blindweg
|
|
toepassen of ervan uitgaan dat er niets aangepast moet worden als er geen
|
|
diff is zonder zelf op eventuele wijzigingen te controleren, kan leiden tot
|
|
pakketten met verslapte afhankelijkheidsrelaties die onterecht laten
|
|
veronderstellen dat ze met oudere pakketten kunnen samenwerken. Dit kan bij
|
|
(gedeeltelijke) opwaarderingen leiden tot moeilijk te vinden bugs.
|
|
<A NAME="lbAF"> </A>
|
|
<H3>Substitutie van #PACKAGE# gebruiken</H3>
|
|
|
|
<P>
|
|
|
|
In enkele zeldzame gevallen verschilt de naam van de bibliotheek naargelang
|
|
de architectuur. Om de naam van het pakket niet rechtstreeks in het
|
|
symbolenbestand te moeten inschrijven, kunt u gebruik maken van de marker
|
|
<I>#PACKAGE#</I>. Die zal tijdens de installatie van de symbolenbestanden
|
|
vervangen worden door de echte pakketnaam. In tegenstelling tot de marker
|
|
<I>#MINVER#</I>, zal <I>#PACKAGE#</I> nooit te vinden zijn in een symbolenbestand
|
|
binnenin een binair pakket.
|
|
<A NAME="lbAG"> </A>
|
|
<H3>Symbooltags gebruiken</H3>
|
|
|
|
<P>
|
|
|
|
Het gebruik van symbooltags is nuttig om symbolen te markeren die op een of
|
|
andere manier bijzonder zijn. Aan elk symbool kan een arbitrair aantal tags
|
|
gekoppeld worden. Hoewel alle tags ontleed en opgeslagen worden, worden
|
|
slechts een aantal ervan herkend door <B>dpkg-gensymbols</B>. Ze lokken een
|
|
speciale behandeling van de symbolen uit. Zie het onderdeel <B>Standaard
|
|
symbooltags</B> voor een voorstelling van deze tags.
|
|
<P>
|
|
|
|
Tags worden vlak voor de symboolnaam opgegeven (tussenin mag er geen
|
|
witruimte zijn). Een opgave begint steeds met het openen van een haakje <B>(</B>
|
|
en eindigt met het sluiten ervan <B>)</B> en moet minstens één tag
|
|
bevatten. Meerdere tags worden onderling gescheiden door een
|
|
<B>|</B>-teken. Elke tag kan een facultatieve waarde hebben die van de naam van
|
|
de tag gescheiden wordt door het teken <B>=</B>. Namen van tags en waarden
|
|
kunnen arbitraire tekenreeksen zijn, behalve dat zij niet de speciale tekens
|
|
<B>)</B> <B>|</B> <B>=</B> mogen bevatten. De symboolnaam die na een tagopgave komt kan
|
|
facultatief tussen aanhalingstekens geplaatst worden, ofwel met <B>'</B> of met
|
|
<B>"</B>, waardoor hij witruimte mag bevatten. Evenwel, indien er voor het
|
|
symbool geen tags opgegeven werden, zullen de aanhalingstekens behandeld
|
|
worden als onderdeel van de naam van het symbool die eindigt bij de eerste
|
|
spatie.
|
|
<P>
|
|
|
|
<BR> (tag1=ik werd gemarkeerd|tagnaam met spatie)"getagd en aangehaald symbool"@Base 1.0
|
|
<BR> (optional)<A HREF="mailto:getagd_niet-aangehaald_symbool@Base">getagd_niet-aangehaald_symbool@Base</A> 1.0 1
|
|
<BR> <A HREF="mailto:niet-getagd_symbool@Base">niet-getagd_symbool@Base</A> 1.0
|
|
<P>
|
|
|
|
Het eerste symbool in het voorbeeld werd <I>getagd en aangehaald symbool</I>
|
|
genoemd en heeft twee tags: <I>tag1</I> met als waarde <I>ik werd gemarkeerd</I> en
|
|
<I>tagnaam met spatie</I> die geen waarde heeft. Het tweede symbool met als naam
|
|
<I>getagd_niet-aangehaald_symbool</I> werd enkel gemarkeerd met de tag die
|
|
<I>optional</I> als naam heeft. Het laatste symbool is een voorbeeld van een
|
|
normaal niet-gemarkeerd symbool.
|
|
<P>
|
|
|
|
Aangezien symbooltags een uitbreiding zijn van het
|
|
<B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5)-systeem, kunnen zij enkel deel uitmaken van de
|
|
symbolenbestanden die in broncodepakketten gebruikt worden (die bestanden
|
|
moeten dan gezien worden als sjablonen die gebruikt worden om de
|
|
symbolenbestanden te bouwen die in de binaire pakketten zitten). Indien
|
|
<B>dpkg-gensymbols</B> aangeroepen wordt zonder de optie <B>-t</B> zal het
|
|
symbolenbestanden produceren die compatibel zijn met het
|
|
<B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5)-systeem: er gebeurt een volledige verwerking van de
|
|
symbolen in overeenstemming met de vereisten van hun standaardtags en de
|
|
uitvoer wordt ontdaan van alle tags. In sjabloonmodus (<B>-t</B>) daarentegen
|
|
blijven in de uitvoer alle symbolen en hun tags (zowel de standaardtags als
|
|
de niet-gekende) behouden en worden ze in hun originele vorm neergeschreven
|
|
zoals ze geladen werden.
|
|
<A NAME="lbAH"> </A>
|
|
<H3>Standaard symbooltags</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="5"><B>optional</B><DD>
|
|
Een symbool dat als optional (facultatief) gemarkeerd is, kan om het even
|
|
wanneer uit de bibliotheek verdwijnen en dat feit zal nooit een mislukking
|
|
van <B>dpkg-gensymbols</B> tot gevolg hebben. Nochtans zullen verdwenen
|
|
facultatieve symbolen permanent als MISSING (ontbrekend) aangegeven worden
|
|
in de diff (weergave van de veranderingen) bij elke nieuwe
|
|
pakketrevisie. Dit gedrag dient als een geheugensteuntje voor de onderhouder
|
|
dat een dergelijk symbool verwijderd moet worden uit het symbolenbestand of
|
|
terug toegevoegd aan de bibliotheek. Indien een facultatief symbool dat
|
|
eerder als MISSING opgetekend stond in een volgende revisie plots opnieuw
|
|
terug opduikt, zal het terug opgewaardeerd worden naar de status "existing"
|
|
(bestaand) zonder wijziging van zijn minimumversie.
|
|
<P>
|
|
Deze tag is nuttig voor private symbolen waarvan de verdwijning geen
|
|
ABI-breuk veroorzaakt. De meeste van de C++-sjabloon-instantiaties vallen
|
|
bijvoorbeeld onder deze categorie. Zoals elke andere tag kan ook deze een
|
|
arbitraire waarde hebben: die kan gebruikt worden om aan te geven waarom het
|
|
symbool als facultatief beschouwd wordt.
|
|
<DT id="6"><B>arch=</B><I>architectuurlijst</I><DD>
|
|
|
|
<B>arch-bits=</B><I>architectuur-bits</I>
|
|
|
|
<B>arch-endian=</B><I>architectuur-endianness</I>
|
|
Deze tags laten iemand toe om de set architecturen waarvoor het symbool
|
|
verondersteld wordt te bestaan, te beperken. De tags <B>arch-bits</B> en
|
|
<B>arch-endian</B> worden sinds dpkg 1.18.0 ondersteund. Als de symbolenlijst
|
|
bijgewerkt wordt met de symbolen die in de bibliotheek gevonden worden,
|
|
worden alle architectuurspecifieke symbolen die van geen belang zijn voor de
|
|
huidige hostarchitectuur, behandeld alsof ze niet bestaan. Indien een
|
|
architectuurspecifiek symbool dat betrekking heeft op de huidige
|
|
hostarchitectuur, ontbreekt in de bibliotheek, zijn de normale procedures
|
|
die gelden voor ontbrekende symbolen, van toepassing en dit kan het
|
|
mislukken van <B>dpkg-gensymbols</B> tot gevolg hebben. Anderzijds, indien het
|
|
architectuurspecifieke symbool aangetroffen wordt als het er niet
|
|
verondersteld wordt te zijn (omdat de huidige hostarchitectuur niet vermeld
|
|
wordt in de tag of niet overeenkomt met de endianness of de bits), dan wordt
|
|
het architectuurneutraal gemaakt (d.w.z. dat de tags arch, arch-bits en
|
|
arch-endian weggelaten worden en het symbool omwille van deze verandering in
|
|
de diff (weergave van de veranderingen) opgenomen zal worden), maar het
|
|
wordt niet als nieuw beschouwd.
|
|
<P>
|
|
Als in de standaardmodus (niet-sjabloonmodus) gewerkt wordt, worden van de
|
|
architectuurspecifieke symbolen enkel die in het symbolenbestand
|
|
opgeschreven die overeenkomen met de huidige hostarchitectuur. Als
|
|
daarentegen in de sjabloonmodus gewerkt wordt, worden steeds alle
|
|
architectuurspecifieke symbolen (ook die voor vreemde architecturen)
|
|
opgeschreven in het symbolenbestand.
|
|
<P>
|
|
De indeling voor de <I>architectuurlijst</I> is dezelfde als die welke gebruikt
|
|
wordt voor het veld <B>Build-Depends</B> van <I>debian/control</I> (behalve de
|
|
omsluitende vierkante haakjes []). Met het eerste symbool uit de
|
|
onderstaande lijst zal bijvoorbeeld enkel rekening gehouden worden bij de
|
|
architecturen alpha, any-amd64 en ia64, met het tweede enkel op
|
|
linux-architecturen en met het derde overal behalve op armel.
|
|
<P>
|
|
<BR> (arch=alpha any-amd64 ia64)<A HREF="mailto:een_64bits_specifiek_symbool@Base">een_64bits_specifiek_symbool@Base</A> 1.0
|
|
<BR> (arch=linux-any)<A HREF="mailto:linux_specifiek_symbool@Base">linux_specifiek_symbool@Base</A> 1.0
|
|
<BR> (arch=!armel)<A HREF="mailto:symbool_dat_armel_niet_heeft@Base">symbool_dat_armel_niet_heeft@Base</A> 1.0
|
|
<P>
|
|
De waarde van <I>architectuur-bits</I> is ofwel <B>32</B> of <B>64</B>.
|
|
<P>
|
|
<BR> (arch-bits=32)<A HREF="mailto:32bits_specifiek_symbool@Base">32bits_specifiek_symbool@Base</A> 1.0
|
|
<BR> (arch-bits=64)<A HREF="mailto:64bits_specifiek_symbool@Base">64bits_specifiek_symbool@Base</A> 1.0
|
|
<P>
|
|
De waarde van <I>architectuur-endianness</I> is ofwel <B>little</B> of <B>big</B>.
|
|
<P>
|
|
<BR> (arch-endian=little)<A HREF="mailto:little_endian_specifiek_symbool@Base">little_endian_specifiek_symbool@Base</A> 1.0
|
|
<BR> (arch-endian=big)<A HREF="mailto:big_endian_specifiek_symbool@Base">big_endian_specifiek_symbool@Base</A> 1.0
|
|
<P>
|
|
Meerdere beperkingen kunnen aaneengeregen worden.
|
|
<P>
|
|
<BR> (arch-bits=32|arch-endian=little)<A HREF="mailto:32bits_le_symbool@Base">32bits_le_symbool@Base</A> 1.0
|
|
<DT id="7"><B>ignore-blacklist</B><DD>
|
|
dpkg-gensymbols hanteert een interne zwarte lijst van symbolen die niet
|
|
zouden mogen voorkomen in symbolenbestanden omdat ze gewoonlijk slechts een
|
|
neveneffect zijn van details in de wijze waarop de gereedschapskist
|
|
(toolchain) geïmplementeerd wordt. Indien u om een of andere reden echt wilt
|
|
dat een van deze symbolen opgenomen wordt in het symbolenbestand, moet u het
|
|
symbool markeren met de tag <B>ignore-blacklist</B>. Dit kan nodig zijn voor
|
|
sommige gereedschapskistbibliotheken van lagere orde zoals libgcc
|
|
<DT id="8"><B>c++</B><DD>
|
|
Geeft een <I>c++</I>-symboolpatroon aan. Zie hierna in de subsectie <B>Het
|
|
gebruik van symboolpatronen</B>.
|
|
<DT id="9"><B>symver</B><DD>
|
|
Geeft een <I>symver</I> (symboolversie) symboolpatroon aan. Zie hierna in de
|
|
subsectie <B>Het gebruik van symboolpatronen</B>.
|
|
<DT id="10"><B>regex</B><DD>
|
|
Geeft een <I>regex</I>-symboolpatroon aan. Zie hierna in de subsectie <B>Het
|
|
gebruik van symboolpatronen</B>.
|
|
</DL>
|
|
<A NAME="lbAI"> </A>
|
|
<H3>Het gebruik van symboolpatronen</H3>
|
|
|
|
<P>
|
|
|
|
Anders dan een standaardbeschrijving van een symbool, kan een patroon
|
|
meerdere echte symbolen uit de bibliotheek dekken. <B>dpkg-gensymbols</B> zal
|
|
proberen om elk patroon te vergelijken met elk reëel symbool waarvoor in het
|
|
symbolenbestand <I>geen</I> specifiek symboolpendant gedefinieerd werd. Telkens
|
|
wanneer een eerste overeenkomst met een patroon gevonden wordt, worden alle
|
|
tags en eigenschappen ervan gebruikt als basisspecificatie voor het
|
|
symbool. Indien er met geen enkel patroon een overeenkomst gevonden wordt,
|
|
zal het symbool als nieuw beschouwd worden.
|
|
<P>
|
|
Een patroon wordt als verloren beschouwd als het met geen enkel symbool uit
|
|
de bibliotheek overeenkomt. Standaard zal dit onder <B>-c1</B> of een hoger
|
|
niveau een mislukking van <B>dpkg-gensymbols</B> uitlokken. Indien een
|
|
dergelijke mislukking echter onwenselijk is, kan het patroon gemarkeerd
|
|
worden met de tag <I>optional</I>. Als het patroon in dat geval geen
|
|
overeenkomst oplevert, zal het enkel in de diff (weergave van de
|
|
wijzigingen) als MISSING (ontbrekend) vermeld worden. Zoals elk ander
|
|
symbool kan ook een patroon beperkt worden tot specifieke architecturen met
|
|
de tag <I>arch</I>. Raadpleeg het onderdeel <B>Standaard symbooltags</B> hierboven
|
|
voor meer informatie.
|
|
<P>
|
|
Patronen vormen een uitbreiding van het <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5)-systeem en zijn
|
|
daarom enkel geldig in symbolenbestandsjablonen. De syntaxis voor het
|
|
opgeven van patronen verschilt niet van die voor een specifiek symbool. Het
|
|
onderdeel symboolnaam van de specificatie fungeert echter als een expressie
|
|
die vergeleken wordt met <I><A HREF="mailto:naam@versie">naam@versie</A></I> van het echte symbool. Om het
|
|
onderscheid te maken tussen verschillende types patronen, wordt een patroon
|
|
doorgaans gemarkeerd met een speciale tag
|
|
<P>
|
|
Op dit ogenblik ondersteunt <B>dpkg-gensymbols</B> drie fundamentele
|
|
patroontypes:
|
|
<DL COMPACT>
|
|
<DT id="11"><B>c++</B><DD>
|
|
Dit patroon wordt met de tag <I>c++</I> aangeduid. Het zoekt enkel een
|
|
overeenkomst met C++-symbolen aan de hand van hun ontwarde (demangled)
|
|
symboolnaam (zoals die weergegeven wordt door het hulpprogramma
|
|
<B>c++<A HREF="/cgi-bin/man/man2html?1+filt">filt</A></B>(1)). Dit patroon is zeer handig om symbolen te vinden waarvan de
|
|
verhaspelde naam op verschillende architecturen anders kan zijn, terwijl hun
|
|
ontwarde naam gelijk blijft. Een groep van dergelijke symbolen is
|
|
<I>non-virtual thunks</I> die architectuurspecifieke geheugenplaatsen ingebed
|
|
hebben in hun verhaspelde naam. Een courant voorkomend voorbeeld hiervan is
|
|
een virtuele destructor die onder een diamantovererving een niet-virtueel
|
|
thunk-symbool nodig heeft. Bijvoorbeeld, zelfs als
|
|
<A HREF="mailto:_ZThn8_N3NSB6ClassDD1Ev@Base">_ZThn8_N3NSB6ClassDD1Ev@Base</A> op 32-bits-architecturen wellicht
|
|
<A HREF="mailto:_ZThn16_N3NSB6ClassDD1Ev@Base">_ZThn16_N3NSB6ClassDD1Ev@Base</A> zal zijn op 64-bits-architecturen, kunnen zij
|
|
met één enkel <I>c++</I>-patroon aangeduid worden:
|
|
<P>
|
|
libdummy.so.1 libdummy1 #MINVER#
|
|
<BR> [...]
|
|
<BR> (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
|
|
<BR> [...]
|
|
<P>
|
|
De bovenstaande ontwarde naam kan verkregen worden door het volgende
|
|
commando uit te voeren:
|
|
<P>
|
|
<BR> $ echo '<A HREF="mailto:_ZThn8_N3NSB6ClassDD1Ev@Base">_ZThn8_N3NSB6ClassDD1Ev@Base</A>' | c++filt
|
|
<P>
|
|
Merk op dat een verhaspelde naam per definitie uniek is in de bibliotheek,
|
|
maar dat dit niet noodzakelijk het geval is voor ontwarde namen. Een aantal
|
|
verschillende echte symbolen kan dezelfde ontwarde naam hebben. Dat is
|
|
bijvoorbeeld het geval met niet-virtuele thunk-symbolen in complexe
|
|
overervingsconfiguraties of met de meeste constructors en destructors
|
|
(vermits g++ voor hen doorgaans twee echte symbolen genereert). Vermits deze
|
|
collisies zich op het ABI-niveau voordoen, verminderen zij evenwel niet de
|
|
kwaliteit van het symbolenbestand.
|
|
<DT id="12"><B>symver</B><DD>
|
|
Dit patroon wordt door de tag <I>symver</I> aangegeven. Goed onderhouden
|
|
bibliotheken hebben symbolen met versienummers, waarbij elke versie
|
|
overeenkomt met de toeleveraarsversie waar het symbool toegevoegd
|
|
werd. Indien dat het geval is, kunt u een <I>symver</I>-patroon gebruiken om
|
|
eventuele symbolen aan te duiden die gekoppeld zijn aan de specifieke
|
|
versie. Bijvoorbeeld:
|
|
<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 symbolen die horen bij de versies GLIBC_2.0 en GLIBC_2.7 zullen
|
|
resulteren in de respectieve minimale versies 2.0 en 2.7, met uitzondering
|
|
van het symbool <A HREF="mailto:access@GLIBC_2.0">access@GLIBC_2.0</A>. Dit laatste zal resulteren in een minimale
|
|
vereiste van libc6 versie 2.2 en dit ondanks het feit dat het valt binnen
|
|
het bereik van het patroon "(symver)GLIBC_2.0". De reden hiervoor is dat
|
|
specifieke symbolen voorrang hebben op patronen.
|
|
<P>
|
|
Merk op dat hoewel patronen met jokertekens volgens de oude stijl (in het
|
|
veld symboolnaam aangegeven door "*@version") nog steeds ondersteund worden,
|
|
zij vervangen werden door een syntaxis volgens de nieuwe stijl
|
|
"(symver|optional)version". Als hetzelfde effect gewenst wordt moet
|
|
bijvoorbeeld "*@GLIBC_2.0 2.0" geschreven worden als
|
|
"(symver|optional)GLIBC_2.0 2.0".
|
|
<DT id="13"><B>regex</B><DD>
|
|
Patronen in de vorm van reguliere expressies worden aangegeven met de tag
|
|
<I>regex</I>. Zij zoeken naar een overeenkomst met de in het veld symboolnaam
|
|
vermelde perl reguliere expressie. Een reguliere expressie wordt als zodanig
|
|
vergeleken. Daarom mag u niet vergeten ze te laten beginnen met het teken
|
|
<I>^</I>. Anders kan ze een overeenkomst opleveren met om het even welk deel van
|
|
de tekenreeks <I><A HREF="mailto:naam@versie">naam@versie</A></I> van het echte symbool. Bijvoorbeeld:
|
|
<P>
|
|
libdummy.so.1 libdummy1 #MINVER#
|
|
<BR> (regex)"^mystack_.*@Base$" 1.0
|
|
<BR> (regex|optional)"private" 1.0
|
|
<P>
|
|
Symbolen zoals "<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>"
|
|
enz. zullen door het eerste patroon gevonden worden, terwijl
|
|
"<A HREF="mailto:ng_mystack_new@Base">ng_mystack_new@Base</A>" bijvoorbeeld niet. Het tweede patroon zal een
|
|
overeenkomst opleveren met alle symbolen die in hun naam de tekenreeks
|
|
"private" hebben en de gevonden symbolen zullen de tag <I>optional</I> overerven
|
|
van het patroon.
|
|
</DL>
|
|
<P>
|
|
|
|
De hierboven vermelde basispatronen kunnen met elkaar gecombineerd worden
|
|
als dat zinvol is. In dat geval worden zij verwerkt in de volgorde waarin de
|
|
tags opgegeven werden. Bijvoorbeeld beide onderstaande patronen
|
|
<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>
|
|
zullen de symbolen "<A HREF="mailto:_ZN3NSA6ClassA7Private11privmethod1Ei@Base">_ZN3NSA6ClassA7Private11privmethod1Ei@Base</A>" en
|
|
"<A HREF="mailto:_ZN3NSA6ClassA7Private11privmethod2Ei@Base">_ZN3NSA6ClassA7Private11privmethod2Ei@Base</A>" vinden. Bij het vergelijken met
|
|
het eerste patroon wordt het rauwe symbool eerst ontward als een C++-symbool
|
|
en vervolgens wordt de ontwarde naam vergeleken met de reguliere
|
|
expressie. Bij het vergelijken met het tweede patroon daarentegen, wordt de
|
|
reguliere expressie vergeleken met de rauwe symboolnaam en vervolgens wordt
|
|
nagegaan of het een C++-symbool is door het te proberen ontwarren. Als een
|
|
basispatroon een mislukking oplevert, betekent dit het mislukken van het
|
|
hele patroon. Om die reden zal
|
|
"__N3NSA6ClassA7Private11privmethod\<A HREF="mailto:dEi@Base">dEi@Base</A>" bijvoorbeeld met geen van
|
|
beide patronen een overeenkomst opleveren, aangezien het geen geldig
|
|
C++-symbool is.
|
|
<P>
|
|
Over het algemeen genomen kunnen alle patronen in twee groepen onderverdeeld
|
|
worden: aliassen (basale <I>c++</I>- en <I>symver</I>-patronen) en generieke
|
|
patronen (<I>regex</I>, alle combinaties van meerdere basale patronen). Het
|
|
vergelijken met basale patronen van het alias-type verloopt snel (<A HREF="/cgi-bin/man/man2html?1+O">O</A>(1)),
|
|
terwijl dat bij generieke patronen voor elk symbool O(N) is (waarbij N het
|
|
aantal generieke patronen is). Daarom wordt aangeraden om geen overdadig
|
|
gebruik te maken van generieke patronen.
|
|
<P>
|
|
Indien meerdere patronen een overeenkomst opleveren met hetzelfde echte
|
|
symbool, krijgen aliassen (eerst <I>c++</I>, dan <I>symver</I>) de voorkeur boven
|
|
generieke patronen. Generieke patronen worden vergeleken in de volgorde
|
|
waarin zij aangetroffen worden in het symbolenbestandsjabloon tot er een
|
|
eerste succes volgt. Merk nochtans op dat het manueel herordenen van items
|
|
uit het sjabloonbestand niet aangeraden wordt, aangezien <B>dpkg-gensymbols</B>
|
|
diffs (weergave van de veranderingen) genereert op basis van de
|
|
alfanumerieke volgorde van hun namen.
|
|
<A NAME="lbAJ"> </A>
|
|
<H3>Het gebruik van includes</H3>
|
|
|
|
<P>
|
|
|
|
Als de set van geëxporteerde symbolen onderling verschilt tussen
|
|
verschillende architecturen, kan het inefficiënt worden om één enkel
|
|
symbolenbestand te gebruiken. In die gevallen kan een include-opdracht op
|
|
een aantal wijzen nuttig blijken:
|
|
<DL COMPACT>
|
|
<DT id="14">•<DD>
|
|
U kunt het gemeenschappelijke gedeelte afsplitsen in een extern bestand en
|
|
dat bestand opnemen in uw bestand <I>pakket</I>.symbols.<I>arch</I> met behulp van
|
|
een include-opdracht op de volgende manier:
|
|
<P>
|
|
#include "<I>pakketten</I>.symbols.common"
|
|
<DT id="15">•<DD>
|
|
Net zoals om het even welk symbool kan ook een include-opdracht tags
|
|
krijgen:
|
|
<P>
|
|
(tag|...|tagN)#include "in-te-voegen-bestand"
|
|
<P>
|
|
Als gevolg daarvan zal er standaard van uitgegaan worden dat alle symbolen
|
|
die uit <I>in-te-voegen-bestand</I> opgenomen worden, gemarkeerd zijn met <I>tag</I>
|
|
... <I>tagN</I>. U kunt van deze functionaliteit gebruik maken om een
|
|
gemeenschappelijk bestand <I>pakket</I>.symbols te maken waarin
|
|
architectuurspecifieke symbolenbestanden opgenomen worden:
|
|
<P>
|
|
<BR> <A HREF="mailto:gemeenschappelijk_symbool1@Base">gemeenschappelijk_symbool1@Base</A> 1.0
|
|
<BR> (arch=amd64 ia64 alpha)#include "pakket.symbolen.64bits"
|
|
<BR> (arch=!amd64 !ia64 !alpha)#include "pakket.symbolen.32bits"
|
|
<BR> <A HREF="mailto:gemeenschappelijk_symbool2@Base">gemeenschappelijk_symbool2@Base</A> 1.0
|
|
</DL>
|
|
<P>
|
|
|
|
De symbolenbestanden worden regel per regel gelezen en include-opdrachten
|
|
worden verwerkt van zodra ze tegengekomen worden. Dit betekent dat de inhoud
|
|
van het ingevoegde bestand eventueel zaken kan vervangen die voor de
|
|
include-opdracht stonden en dat zaken die na de opdracht komen, eventueel
|
|
inhoud uit het ingevoegde bestand kunnen vervangen. Elk symbool (of zelfs
|
|
een andere #include-opdracht) uit het ingevoegde bestand kan bijkomende tags
|
|
opgeven of via zijn tag-vermeldingen waarden van de overgeërfde tags
|
|
vervangen. Er bestaat nochtans geen manier waarop een symbool eventueel
|
|
overgeërfde tags zou kunnen verwijderen.
|
|
<P>
|
|
|
|
Een ingevoegd bestand kan de kopregel die de SONAME van de bibliotheek
|
|
bevat, herhalen. In dat geval vervangt het een eventueel eerder ingelezen
|
|
kopregel. Het is over het algemeen nochtans best om het dupliceren van
|
|
kopregels te vermijden. Een manier om dat te doen is de volgende:
|
|
<P>
|
|
|
|
#include "libding1.symbols.common"
|
|
<BR> <A HREF="mailto:arch_specifiek_symbool@Base">arch_specifiek_symbool@Base</A> 1.0
|
|
<A NAME="lbAK"> </A>
|
|
<H3>Goed beheer van bibliotheken</H3>
|
|
|
|
<P>
|
|
|
|
Een goed onderhouden bibliotheek heeft de volgende functionaliteit:
|
|
<DL COMPACT>
|
|
<DT id="16">•<DD>
|
|
haar API is stabiel (publieke symbolen worden nooit verwijderd, enkel worden
|
|
nieuwe publieke symbolen toegevoegd) en zij ondergaat enkel op een
|
|
incompatibele manier veranderingen als de SONAME verandert;
|
|
<DT id="17">•<DD>
|
|
idealiter gebruikt zij symboolversienummering om ondanks interne wijzigingen
|
|
en API-uitbreidingen ABI-stabiliteit te bekomen;
|
|
<DT id="18">•<DD>
|
|
zij exporteert geen private symbolen (dergelijke symbolen kunnen de tag
|
|
optional krijgen om dat te omzeilen).
|
|
</DL>
|
|
<P>
|
|
|
|
Bij het onderhoud van een symbolenbestand is het gemakkelijk om het
|
|
verschijnen en verdwijnen van symbolen op te merken. Maar het is moeilijker
|
|
om incompatibele API- en ABI-wijzigingen op te merken. Daarom moet de
|
|
onderhouder het changelog-bestand van de toeleveraar grondig nakijken op
|
|
situaties waarbij de regels van goed bibliotheekbeheer geschonden
|
|
worden. Indien mogelijke problemen ontdekt worden, zou de toeleverende
|
|
auteur erover ingelicht moeten worden, aangezien een reparatie op het niveau
|
|
van de toeleveraar altijd te verkiezen valt boven een Debian-specifieke
|
|
tijdelijke oplossing.
|
|
<A NAME="lbAL"> </A>
|
|
<H2>OPTIES</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="19"><B>-P</B><I>pakketbouwmap</I><DD>
|
|
Zoek in <I>pakketbouwmap</I> in plaats van in debian/tmp.
|
|
<DT id="20"><B>-p</B><I>pakket</I><DD>
|
|
Definieer de pakketnaam. Is vereist als meer dan één binair pakket vermeld
|
|
wordt in debian/control (of indien er geen bestand debian/control is).
|
|
<DT id="21"><B>-v</B><I>versie</I><DD>
|
|
Definieer de pakketversie. Standaard is dat de versie die uit
|
|
debian/changelog gehaald wordt. Is vereist indien het aanroepen gebeurt van
|
|
buiten de boom van het broncodepakket.
|
|
<DT id="22"><B>-e</B><I>bibliotheekbestand</I><DD>
|
|
Analyseer enkel de expliciet vermelde bibliotheken in plaats van alle
|
|
publieke bibliotheken te zoeken. U kunt in <I>bibliotheekbestand</I> gebruik
|
|
maken van shell-patronen met het oog op padnaamexpansie (zie de man-pagina
|
|
<B>File::Glob</B>(3perl) voor details) om met één enkel argument meerdere
|
|
bibliotheken aan te duiden (anders heeft u meerdere malen <B>-e</B> nodig).
|
|
<DT id="23"><B>-l</B><I>map</I><DD>
|
|
Voeg <I>map</I> vooraan toe aan de lijst van mappen waarin naar private gedeelde
|
|
bibliotheken gezocht moet worden (sinds dpkg 1.19.1). Deze optie kan
|
|
meermaals gebruikt worden.
|
|
<P>
|
|
Opmerking: gebruik deze optie in de plaats van het instellen van
|
|
<B>LD_LIBRARY_PATH</B>, aangezien die omgevingsvariabele gebruikt wordt om de
|
|
runtime linker aan te sturen. Daarvan misbruik maken om de paden van
|
|
gedeelde bibliotheken in te stellen tijdens het bouwen van het programma,
|
|
kan problematisch zijn, bijvoorbeeld bij het cross-compileren.
|
|
<DT id="24"><B>-I</B><I>bestandsnaam</I><DD>
|
|
Gebruik <I>bestandsnaam</I> als referentiebestand om het symbolenbestand te
|
|
genereren dat in het pakket zelf geïntegreerd wordt.
|
|
<DT id="25"><B>-O</B>[<I>bestandsnaam</I>]<DD>
|
|
Geef het gegenereerde symbolenbestand uit weer op de standaarduitvoer of
|
|
schrijf het naar <I>bestandsnaam</I> als dat opgegeven werd, eerder dan naar
|
|
<B>debian/tmp/DEBIAN/symbols</B> (of <I>pakketbouwmap</I><B>/DEBIAN/symbols</B> indien
|
|
<B>-P</B> gebruikt werd). Indien <I>bestandsnaam</I> reeds bestond, wordt de inhoud
|
|
ervan gebruikt als basis voor het gegenereerde symbolenbestand. U kunt van
|
|
deze functionaliteit gebruik maken om een symbolenbestand bij te werken
|
|
zodat het in overeenstemming is met een nieuwere toeleveraarsversie van uw
|
|
bibliotheek.
|
|
<DT id="26"><B>-t</B><DD>
|
|
Schrijf het symbolenbestand in sjabloonmodus eerder dan in de indeling die
|
|
compatibel is met <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5). Het grootste verschil is dat in de
|
|
sjabloonmodus symboolnamen en tags geschreven worden in hun originele vorm
|
|
in tegenstelling tot in de compatibele modus waarin de verwerkte
|
|
symboolnamen ontdaan van hun tags gebruikt worden. Daarenboven kunnen bij
|
|
het schrijven van een standaard <B><A HREF="/cgi-bin/man/man2html?5+deb-symbols">deb-symbols</A></B>(5)-bestand sommige symbolen
|
|
weggelaten worden (overeenkomstig de regels voor het verwerken van tags),
|
|
terwijl in een symbolenbestandsjabloon steeds alle symbolen neergeschreven
|
|
worden.
|
|
<DT id="27"><B>-c</B><I>[0-4]</I><DD>
|
|
Definieer de controles die moeten gebeuren bij het vergelijken van het
|
|
gegenereerde symbolenbestand met het sjabloonbestand dat als vertrekpunt
|
|
gebruikt werd. Standaard is dat volgens niveau 1. Het verhogen van het
|
|
niveau leidt tot meer controles, terwijl alle controles van lagere niveaus
|
|
behouden blijven. Niveau 0 leidt nooit tot een mislukking. Niveau 1 mislukt
|
|
als er symbolen verdwenen zijn. Niveau 2 geeft een mislukking als nieuwe
|
|
symbolen geïntroduceerd werden. Niveau 3 mislukt als er bibliotheken
|
|
verdwenen zijn. Niveau 4 geeft een mislukking als nieuwe bibliotheken
|
|
geïntroduceerd werden.
|
|
<P>
|
|
Deze waarde kan vervangen worden door de omgevingsvariabele
|
|
<B>DPKG_GENSYMBOLS_CHECK_LEVEL</B>.
|
|
<DT id="28"><B>-q</B><DD>
|
|
Gedraag u rustig en genereer nooit een diff (een overzicht van de
|
|
verschillen) tussen het gegenereerde symbolenbestand en het sjabloonbestand
|
|
dat als vertrekpunt gebruikt werd en toon geen enkele waarschuwing in
|
|
verband met nieuwe/verloren bibliotheken of nieuwe/verloren symbolen. Deze
|
|
optie schakelt enkel de informatieve uitvoer uit, maar niet de controles
|
|
zelf (zie de optie <B>-c</B>).
|
|
<DT id="29"><B>-a</B><I>arch</I><DD>
|
|
Ga uit van <I>arch</I> als hostarchitectuur bij het verwerken van
|
|
symbolenbestanden. Gebruik deze optie om een symbolenbestand of een diff
|
|
(overzicht van de verschillen) voor een willekeurige architectuur te
|
|
genereren op voorwaarde dat de binaire bestanden ervan reeds voorhanden
|
|
zijn.
|
|
<DT id="30"><B>-d</B><DD>
|
|
Zet debug-modus aan. Talrijke berichten worden dan getoond om toe te lichten
|
|
wat <B>dpkg-gensymbols</B> doet.
|
|
<DT id="31"><B>-V</B><DD>
|
|
Schakel de breedsprakige modus in. Het gegenereerde symbolenbestand bevat
|
|
dan verouderde symbolen in de vorm van commentaar. In sjabloonmodus worden
|
|
daarenboven patroonsymbolen gevolgd door commentaar met daarin een opsomming
|
|
van de echte symbolen die met het patroon overeenkwamen.
|
|
<DT id="32"><B>-?</B>, <B>--help</B><DD>
|
|
Toon info over het gebruik en sluit af.
|
|
<DT id="33"><B>--version</B><DD>
|
|
Toon de versie en sluit af.
|
|
</DL>
|
|
<A NAME="lbAM"> </A>
|
|
<H2>OMGEVING</H2>
|
|
|
|
<DL COMPACT>
|
|
<DT id="34"><B>DPKG_GENSYMBOLS_CHECK_LEVEL</B><DD>
|
|
Overschrijft het controleniveau van het commando, zelfs als het argument
|
|
<B>-c</B> opgegeven werd aan de commandoregel (merk op dat dit ingaat tegen de
|
|
algemeen geldende afspraak dat commandoregel-argumenten voorrang hebben op
|
|
omgevingsvariabelen).
|
|
<DT id="35"><B>DPKG_COLORS</B><DD>
|
|
Stelt de kleurmodus in (sinds dpkg 1.18.5). Waarden die momenteel gebruikt
|
|
mogen worden zijn: <B>auto</B> (standaard), <B>always</B> en <B>never</B>.
|
|
<DT id="36"><B>DPKG_NLS</B><DD>
|
|
Indien dit ingesteld is, zal het gebruikt worden om te beslissen over het
|
|
activeren van moedertaalondersteuning, ook gekend als
|
|
internationaliseringsondersteuning (of i18n) (sinds dpkg 1.19.0). Geldige
|
|
waarden zijn: <B>0</B> and <B>1</B> (standaard).
|
|
</DL>
|
|
<A NAME="lbAN"> </A>
|
|
<H2>ZIE OOK</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).
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="37"><A HREF="#lbAB">NAAM</A><DD>
|
|
<DT id="38"><A HREF="#lbAC">OVERZICHT</A><DD>
|
|
<DT id="39"><A HREF="#lbAD">BESCHRIJVING</A><DD>
|
|
<DT id="40"><A HREF="#lbAE">HET ONDERHOUD VAN SYMBOLENBESTANDEN</A><DD>
|
|
<DL>
|
|
<DT id="41"><A HREF="#lbAF">Substitutie van #PACKAGE# gebruiken</A><DD>
|
|
<DT id="42"><A HREF="#lbAG">Symbooltags gebruiken</A><DD>
|
|
<DT id="43"><A HREF="#lbAH">Standaard symbooltags</A><DD>
|
|
<DT id="44"><A HREF="#lbAI">Het gebruik van symboolpatronen</A><DD>
|
|
<DT id="45"><A HREF="#lbAJ">Het gebruik van includes</A><DD>
|
|
<DT id="46"><A HREF="#lbAK">Goed beheer van bibliotheken</A><DD>
|
|
</DL>
|
|
<DT id="47"><A HREF="#lbAL">OPTIES</A><DD>
|
|
<DT id="48"><A HREF="#lbAM">OMGEVING</A><DD>
|
|
<DT id="49"><A HREF="#lbAN">ZIE OOK</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:19 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|