dpkg-1.16.1.1/man/sv/dpkg-gensymbols.1

.\" Author: Raphaël Hertzog
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH dpkg\-gensymbols 1 2011\-08\-14 Debianprojektet dpkg\-verktygen
.SH NAMN
dpkg\-gensymbols \- generera symbolfiler (information om delade bibliotek)
.
.SH SYNOPS
\fBdpkg\-gensymbols\fP [\fIflagga\fP...]
.
.SH BESKRIVNING
\fBdpkg\-gensymbols\fP söker genom en temporärt byggträd (som standard
debian/tmp) efter bibliotek och skapar en \fIsymbols\fP\-fil som beskriver
dem. Denna fil kommer sedan, såvida den inte är tom, att installeras i
DEBIAN\-underkatalogen i byggträdet så att den hamnar i styrinformationen i
paketet.
.P
När dessa filer skapas, används ett par symbolfiler från paketansvariga som
indata. Programmet söker efter följande filer (och använder den första det
finner):
.IP \(bu 4
debian/\fIpaket\fP.symbols.\fIarkitektur\fP
.IP \(bu 4
debian/symbols.\fIarkitektur\fP
.IP \(bu 4
debian/\fIpaket\fP.symbols
.IP \(bu 4
debian/symbols
.P
Dessa filer är i huvudsak intressanta för att kunna tillhandahålla den
minimala version associerad med varje symbol i biblioteken. Detta motsvarar
normalt den första version av paketet som tillhandahöll symbolen, men det
kan manuellt inkrementeras av de ansvariga om symbolens ABI utökas med
bibehållen bakåtkompatibilitet. Det är den ansvarigas ansvar att hålla dessa
filer àjourförda och korrekta, men \fBdpkg\-gensymbols\fP kan hjälpa till.
.P
När den genererade symbolfilen skiljer sig mot den version som
tillhandahållits av de paketansvariga kommer \fBdpkg\-gensymbols\fP att skriva
ut en differens mellan de två versionerna. Om ändringarna är för stora
kommer programmet dessutom att misslyckas (du kan justera hur stora
ändringar du kan tolerera, se flaggan \fB\-c\fP).
.SH "UNDERHÅLLA SYMBOLFILER"
Symbolfilerna är bara riktigt nyttiga om de motsvarar hur paketet har
utvecklats över flera versioner. De paketansvariga måste därför uppdatera
dem varje gång en ny symbol läggs till så att dess associerade minimala
version motsvarar verkligheten. För att göra detta på ett riktigt sätt finns
det differensfiler i byggloggarna. I de flesta fall kan differensfilen
appliceras direkt på filen debian/\fIpaket\fP. Med det i åtanke så behövs det
oftast ytterligare justeringar: det rekommenderas att skippa
Debianrevisionen från det minimala versionsnummer så att den
bakåtanpassningar med ett lägre versionsnummer, men från samma
uppströmsversion, fortfarande uppfyller de genererade beroendena. Om
Debianrevisionen inte kan tas bort på grund av att en symbol faktiskt lades
till av en Debianspecifik ändring så bör ett "~" läggs till i slutet av
versionen.
.P
Innan man applicerar en patch på symbolfilen bör de ansvariga dubbelchecka
att den är korrekt. Publicerade symboler bör inte försvinna, så patchen bör
ideellt sett bara lägga till nya rader.
.P
Obsevera att du kan skriva kommentarer i symbols\-filer: alla rader med "#"
som första tecken är kommentarer, såvida inte det börjar med "#include" (se
stycket \fBAnvända inkluderingar\fP). Rader som börjar med "#MISSING:" är
speciella kommentarer som dokumenterar symboler som har försvunnit.
.SS "Använda #PACKAGE#\-substituering"
.P
I några sällsynta fall skiljer sig namnet på biblioteket mellan
arkitekturer. För att undvika att hårdkoda namnet på paketet i symbolfilen
kan du använda markören \fI#PACKAGE#\fP. Den ersätts av det faktiska
paketnamnet när symbolfilen installeras. Till skillnad från
\fI#MINVER#\fP\-markören kommer \fI#PACKAGE#\fP aldrig att dyka upp i en symbolfil
i ett binärpaket.
.SS "Använda symboltaggar"
.P
Symboltaggning är nyttigt för att markera symboler som är speciella på något
sätt. Alla symboler kan ha ett godtyckligt antal taggar associerade med
sig. Medan alla taggar tolkas och lagras är det bara ett par av dem som
förstås av \fBdpkg\-gensymbols\fP och som utlöser specialhantering av
symbolerna. Se undersymbolen \fBStandardsymboltaggar\fP för mer information om
dessa taggar.
.P
Taggarna anges precis före symbolnamnet (inga blanksteg tillåts mellan). Den
börjar alltid med en vänsterparentes \fB(\fP, slutar med en högerparentes \fB)\fP,
och måste innehålla minst en tagg. Ytterligare taggar avdelas med tecknet
\fB|\fP. En tagg kan ha ett värde, vilket separeras från taggnamnet med tecknet
\fB=\fP. Taggnamn och värden kan vara godtyckliga strängar, förutom att de inte
kan innehålla de speciella tecknen \fB)\fP \fB|\fP \fB=\fP. Symbolnamn som följer en
taggangivelse kan, om så önskas, citeras med antingen \fB'\fP eller \fB"\fP för
att tillåta blanksteg. Om inga taggar anges för symbolen tolkas dock
citattecken som en del av symbolnamnet, vilket fortsätter till det första
blanksteget.
.P
 (tag1=jag är markerad|taggnamn med blanksteg)"taggad citerad symbol"@Bas 1.0
 (optional)taggad_ociterad_symbol@Bas 1.0 1
 ociterad_symbol@Bas 1.0
.P
Den första symbolen i exemplet är heter \fItaggad citerad symbol\fP och har två
taggar: \fItag1\fP med värdet \fIjag är markerad\fP och \fItaggnamn med blanksteg\fP
som inte har något värde. Den andra symbolen heter \fItaggad_ociterad_symbol\fP
och är bara taggad med taggen som heter \fIoptional\fP. Den sista symbolen är
ett exempel på en normal, otaggad symbol.
.P
Eftersom symboltaggar er en utökning av formatet i \fIdeb\-symbols(5)\fP kan de
bara användas i symbolfiler i källkodspaket (dessa filer är att anse som
mallar som används för att bygga symbolfilerna som finns i
binärpaketen). När \fBdpkg\-gensymbols\fP anropas utan flaggan \fI\-t\fP kommer det
att mata ut symbolfiler kompatibla med \fIdeb\-symbols(5)\fP\-formatet: det
hanterar symboler helt beroende på vad som beskrivs av standardtaggarna och
tar bort alla taggar från utdata. I mall\-läge (\fI\-t\fP) kommer däremot alla
symboler och deras taggar (både standard och okända) att behållas i utdata
och skrivas i sin originalform så som de lästes in.
.SS Standardsymboltaggar
.TP 
\fBoptional\fP
En symbol markerad som valfri (optional) kan försvinna från bibliotektet när
som helst och kommer aldrig göra så att \fBdpkg\-gensymbols\fP
misslyckas. Försvunna symboler kommer dock fortfarande visas som saknade
(MISSING) i differensen för varje ny paketversion. Detta beteende fungerar
som en påminnelse för de paketansvariga om att symbolen måste tas bort från
symbolfilen eller läggas tillbaka till biblioteket. När en valfri symbol som
tidigare markerats som saknad (MISSING) plötsligt dyker upp igen i en senare
version kommer den att uppgraderas tillbaka till befintligstatus
("existing") med den minsta tillgängliga versionen oförändrad.

Taggen är användbar för symboler som är privata och vars försvinnande inte
gör att ABI:et går sönder. De flesta C++\-mallinstansieringar faller till
exempel in under denna kategori. Som andra taggar kan den här även ha ett
godtyckligt värde: det kan användas för att indikera varför symbolen är att
anse som valfri.
.TP 
\fBarch=\fP\fIarkitekturlista\fP
Denna tag gör det möjligt att begränsa vilken uppsättning arkitekturer
symbolen är tänkt att finnas för. När symbollistan uppdateras med symboler
som upptäcks i biblioteket behandlas alla arkitekturspecifika symboler som
inte gäller den aktuella värdarkitekturen som om de inte fanns. Om en
arkitekturspecifik symbol som motsvarar den aktuella värdarkitekturen inte
existerar i biblioteket gäller de vanliga reglerna för saknade symboler, och
kan få \fBdpkg\-gensymbols\fP att misslyckas. Å andra sidan, om en
arkitekturspecifik symbol hittas där den inte var menad att finnas (då den
aktuella värdarkitekturen inte är listad i taggen), görs den
arkitekturneutral (dvs. "arch"\-taggen tas bort och symbolen kommer finnas
med i differensen på grund av denna ändring), men den anses inte som ny.

I det vanliga icke\-mall\-läget skrivs endast de arkitekturspecifika symboler
som motsvarar den aktuella värdarkitekturen till symbolfilen. Å andra sidan
skrivs alla arkitekturspecifika symboler (inklusive de från andra
arkitekturer) till symbolfilen i mall\-läget.

Formatet på \fIarkitekturlista\fP är detsamma som det som används i
\fIBuild\-Depends\fP\-fältet i \fIdebian/control\fP (bortsett från de omslutande
hakparenteserna []). Den första symbolen från listan nedan, till exempel,
kommer endast att tas med på arkitekturerna alpha, amd64, kfreebsd\-amd64 och
ia64, medan den andra tas med överallt förutom på armel.

 (arch=alpha amd64 kfreebsd\-amd64 ia64)en_64bit\-specifik_symbol@Base 1.0
 (arch=!armel)symbol_armel_inte_har@Base 1.0
.TP 
\fBignore\-blacklist\fP
dpkg\-gensymbols har en intern svartlista över symboler som inte skall
förekomma i symbolfiler eftersom de oftast bara är sidoeffekter från
implementationsdetaljer i verktygskedjan. Om du, av någon orsak, verkligen
vill att en av dessa symboler skall tas med i symbolfilen måste du tagga
symbolen med \fBignore\-blacklist\fP. Det kan vara nödvändigt för
lågnivå\-verktygskedjebibliotek som libgcc.
.TP 
\fBc++\fP
Betecknar \fIc++\fP\-symbolmönster. Se stycket \fBAnvända symbolmönster\fP nedan.
.TP 
\fBsymver\fP
Anger \fIsymver\fP (symbolversion)\-symbolmönstret. Se stycket \fBAnvända
symbolmönster\fP nedan.
.TP 
\fBregex\fP
Anger \fIregex\fP\-symbolmönstret. Se stycket \fIAnvända symbolmönster\fP nedan.
.SS "Använda symbolmönster"
.P
Till skillnad från vanliga symbolspecifikationer kan ett mönster täcka flera
faktiska symboler från biblioteket. \fBdpkg\-gensymbols\fP kommer försöka matcha
varje mönster mot varje faktisk symbol som \fIinte\fP har en motsvarande
specifik symbol definierad i symbolfilen. Så fort det första mönster som
motsvarar symbolen hittas kommer alla dess taggar och egenskaper att
användas som en basspecifikation för symbolen. Om inget mönster motsvarar
symbolen kommer den att tolkas som ny.

Ett mönster anses som tappat om det inte motsvarar några symboler i
biblioteket. Som standard kommer detta få \fBdpkg\-genchanges\fP att misslyckas
om \fI\-c1\fP eller högre anges. Om ett sådant misslyckande inte är önskvärt kan
mönstret dock märkas med taggen \fIoptional\fP. Om mönstret då inte motsvarar
någonting kommer det bara dyka upp i differensen som saknas
(MISSING). Mönstret kan dessutom, precis som andra symboler, begränsas till
specifika arkitekturer med hjälp av \fIarch\fP\-taggen. Se stycket
\fBStandardsymboltaggar\fP ovan för mer information.

Mönster är en utökning av \fIdeb\-symbols(5)\fP\-formatet och är därför endast
tillåtna i symbolfilmallar. Syntax för angivelse av mönster skiljer sig inte
från den för en specifik symbol. Symbolnamnsdelen av specifikationen
fungerar dock som ett uttryck som skall jämföras mot \fInamn@version\fP för den
faktiska symbolen. För att skilja mellan olika sorters mönster, taggas
mönster normalt med en speciell tagg.

För närvarande stöder \fBdpkg\-gensymbols\fP tre grundläggande mönstertyper:
.TP  3
\fBc++\fP
Detta mönster anges med taggen \fIc++\fP. Den matchar enbart C++\-symboler med
deras avmanglade symbolnamn (som det skrivs ut av
\fBc++filt\fP(1)\-verktyget). Det här mönstret är väldigt nyttigt för att matcha
symboler vars manglade namn kan skilja sig mellan olika arkitekturer, medan
deras avmanglade namn är desamma. En grupp dylika symboler är
\fIicke\-virtuella "thunks"\fP som har arkitekturspecifika offsetvärden inbyggda
i sina manglade namn. En vanlig instans av detta fall är en virtuell
destruktör som under diamantarv behöver en icke\-virtuell
"thunk"\-symbol. Även om till exempel ZThn8_N3NSB6ClassDD1Ev@Base på
32\-bitarsarkitekturer troligtvis är _ZThn16_N3NSB6ClassDD1Ev@Base
på64\-bitarsarkitekturer, så kan de matchas med ett enda \fIc++\fP\-mönster:
.RS
.PP
libdummy.so.1 libdummy1 #MINVER#
 [...]
 (c++)"non\-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
 [...]
.P
Det avmanglade namnet ovan kan hämtas genom att utföra följande kommando:
.PP
 $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
.P
Observera att även om det manglade namnet per definition är unikt i
biblioteket gäller inte detta för avmanglade namn. Flera distinkta verkliga
symboler kan ha samma avmanglade namn. Det gäller till exempel för
icke\-virtuella "thunk"\-symboler i konfigurationer med komplexa arv eller för
de flesta konstruktörer och destruktörer (eftersom g++ normalt genererar två
symboler för dem). Eftersom dessa kollisioner sker på ABI\-nivån bör de dock
inte sänka kvaliteten på symbolfilen.
.RE
.TP 
\fBsymver\fP
Detta mönster anges med taggen \fIsymver\fP. Välunderhållna bibliotek har
versionshanterade symboler där varje version motsvarar uppströmsversionen
där symbolen lades till. Om det är fallet kan du använda ett
\fIsymver\fP\-möster för att matcha alla symboler som matchar den specifika
versionen. Till exempel:
.RS
.PP
libc.so.6 libc6 #MINVER#
 (symver)GLIBC_2.0 2.0
 [...]
 (symver)GLIBC_2.7 2.7
 access@GLIBC_2.0 2.2
.PP
Alla symboler associerade med versionerna GLIBC_2.0 och GLIBC_2.7 kommer
leda till den minimal version 2.0 respektive 2.7, med undantag av symbolen
access@GLIBC_2.0. Den sistnämnda kommer leda till ett minsta beroende på
libc6 version 2.2 trots att den motsvarar mönstret
"(symver)GLIBC_2.0"\-mönstret, eftersom specifika symboler gäller före
mönster.
.P
Observera att även om den gamla sortens jokerteckenmönster (anges med
"*@version" i symbolnamnfältet) fortfarande stöds så rekommenderas de inte
längre i och med den nya sortens syntax "(symver|optional)version". Till
exempel bör "*@GLIBC_2.0 2.0" skrivas som "(symver|optional)GLIBC_2.0 2.0"
om samma beteende behövs.
.RE
.TP 
\fBregex\fP
Mönster med reguljära uttryck anges med taggen \fIregex\fP. De matchar med det
reguljära uttrycket på perl\-form som anges i symbolnamnsfältet. Ett
reguljärt uttryck matchar som det står, glöm därför inte att inleda det med
tecknet \fI^\fP, annars kommer det matcha godtycklig del av den verkliga
symbolens \fInamn@version\fP\-sträng. Till exempel:
.RS
.PP
libdummy.so.1 libdummy1 #MINVER#
 (regex)"^mystack_.*@Base$" 1.0
 (regex|optional)"private" 1.0
.P
Symboler som "mystack_new@Base", "mystack_push@Base", "mystack_pop@Base"
osv. kommer att träffas av det första mönstret medan t.ex
"ng_mystack_new@Base" inte gör det. Det andra mönstret motsvarar alla
symbolen som innehåller strängen "private" i sina namn och träffar kommer
att ärva \fIoptional\fP\-taggen från mönstret.
.RE
.P
Grundläggande mönster som anges ovan kan kombineras där det är vettigt. I så
fall behandlas de i den ordning taggarna anges. Till exempel kommer både
.PP
 (c++|regex)"^NSA::ClassA::Private::privmethod\ed\e(int\e)@Base" 1.0
 (regex|c++)N3NSA6ClassA7Private11privmethod\edEi@Base 1.0
.P
att träffa symbolerna "_ZN3NSA6ClassA7Private11privmethod1Ei@Base" och
"_ZN3NSA6ClassA7Private11privmethod2Ei@Base". När det första mönstret
jämförs avmanglas först symbolen som en C++\-symbol, varefter det avmanglade
namnet jämförs med det reguljära uttrycket. När det andra mönstret jämförs,
å andra sidan, jämförs det reguljära uttrycket mot det råa symbolnamnet,
varefter symbolen testas för att se om det är av C++\-typ genom att försöka
avmangla det. Om ett grundläggande mönster misslyckas kommer hela uttrycket
att misslyckas. Därför kommer, till exempel
"__N3NSA6ClassA7Private11privmethod\edEi@Base" inte att träffas av något av
mönstrena eftersom det inte är en giltig C++\-symbol.
.P
I allmänhet delas alla mönster in i två grupper. alias (grundläggande \fIc++\fP
och \fIsymver\fP) och generella mönster (\fIregex\fP, samtliga kombinationer av
multipla grundläggande mönster). Det går snabbt att träffa grundläggande
aliasbaserade mönster (O(1)) medan generella mönster är O(N) (N \- antal
generella mönster) för varje symbol. Det rekommenderas därför inte att
använda för många generella mönster.
.P
När flera mönster träffar samma verkliga symbol föredras alias (först
\fIc++\fP, sedan \fIsymver\fP) framför generella mönster. Generella mönster
träffas i den ordning de upptäcktes i symbolfilmallen fram till den första
lyckade träffen. Observera dock att manuell omsortering av poster i
mallfilen inte rekommenderas då \fBdpkg\-gensymbols\fP genererar differensfiler
baserad på den alfanumeriska sorteringsordningen av dess namn.
.SS "Använda inkluderingar"
.P
När uppsättningen av exporterade symboler skiljer sig mellan arkitekturer
kan det vara ineffektivt att använda en enda symbolfil. I dessa fall kan ett
inkluderingsdirektiv vara nyttigt på flera sätt:
.IP \(bu 4
Du kan faktorisera de gemensamma delarna i en extern fil och inkludera den
filen i din \fIpaket\fP.symbols.\fIarkitektur\fP\-fil genom att använda ett
inkluderingsdirektiv som detta:

#include "\fIpaket\fP.symbols.common"
.IP \(bu
Inkluderingsdirektivet kan även taggas som alla andra symboler:

(tag|..|tagN)#include "fil\-att\-inkludera"

Alla symboler som inkluderas från \fIfil\-att\-inkludera\fP kommer att anses som
standard vara taggade med \fItag\fP .. \fItagN\fP. Du kan använda denna funktion
för att skapa en gemensam \fIpaket\fP.symbols\-fil som inkluderar
arkitekturspecifika filer:

  gemensam_symbol1@Base 1.0
 (arch=amd64 ia64 alpha)#include "paket.symbols.64bit"
 (arch=!amd64 !ia64 !alpha)#include "paket.symbols.32bit"
  gemensam_symbol2@Base 1.0
.P
Symbolfilerna läses radvis, och inkluderingsdirektiv utförs så fort de
upptäcks. Det betyder att innehållet i den inkluderade filen kan överstyra
allt innehåll som förekom före inkluderingsdirektivet och att innehåll efter
direktivet kan överstyra allt från den inkluderade filen. Alla symboler
(även andra #include\-direktiv) i den inkluderade filen kan ange ytterligare
taggar eller överstyra värden för de ärvda taggarna i sin
taggspecifikation. Det finns dock inte något sätt för en symbol att ta bort
någon av sina ärvda taggar.
.P
En inkluderad fil kan repetera huvudraden som innehåller SONAMNet för
biblioteket. I så fall överstyr den en eventuell huvudrad som lästs in
tidigare. Det är vanligtvis dock bäst att undvika att duplicera
huvudrader. Ett sätt att göra det är som följer:
.PP
#include "libnågonting1.symbols.common"
 arkitekturspecifik_symbol@Base 1.0
.SS "God hantering av bibliotek"
.P
Ett välunderhållet bibliotek har följande funktioner:
.IP \(bu 4
dess API är stabilt (publika symboler tas aldrig bort, endast nya publika
symboler läggs till) och inkompatibla ändringar görs endast när SONAMNet
ändras;
.IP \(bu 4
ideellt använder det en versionhanterade symboler för att upprätthålla
ABI\-stabilitet trots interna ändringar och API\-utökningar;
.IP \(bu 4
det exporterar inte privata symboler (sådana symboler kan taggas med
"optional" för att gå runt detta).
.P
När man underhåller symbolfilen är det lätt att upptäcka symboler som dyker
upp och försvinner. Det är svårare att upptäcka inkompatibla API\- och
ABI\-ändringar. Den paketansvarige bör därför noggrant läsa igenom
uppströmsändringsloggen för fall då reglerna för god hantering av bibliotek
bryts. Om ett möjligt fel upptäcks bör uppströmsförfattaren meddelas, då det
alltid är bättre att problemet rättas uppströms än specifikt i Debian.
.SH FLAGGOR
.TP 
\fB\-P\fP\fIpaketbyggkatalog\fP
Sök \fIpaketbyggkatalog\fP istället för debian/tmp.
.TP 
\fB\-p\fP\fIpaket\fP
Definiera paketnamnet. Krävs om mer än ett binärpaket listas i
debian/control (eller om det inte finns någon debian/control\-fil).
.TP 
\fB\-v\fP\fIversion\fP
Definiera paketversion. Standardvärdet är versionen som hämtas från
debian/changelog. Krävs om programmet anropas utanför ett källkodspaketträd.
.TP 
\fB\-e\fP\fIbiblioteksfil\fP
Analyserar endast bibliotek som listats explicit istället för att hitta alla
publika bibliotek. Du kan använda ett reguljärt uttryck i \fIbiblioteksfil\fP
för att träffa multipla bibliotek med ett enda argument (annars behöver du
flera \fB\-e\fP).
.TP 
\fB\-I\fP\fIfilnamn\fP
Använd \fIfilnamn\fP som referensfil för att generera symbolfilen som
integreras i själva paketet.
.TP 
\fB\-O\fP
Skriv den genererade symbolfilen på standard ut, i stället för att lagra den
i paketets byggträd.
.TP  
\fB\-O\fP\fIfilnamn\fP
Lagra den genererade symbolfilen som \fIfilnamn\fP. Om \fIfilnamn\fP redan
existerar kommer dess innehåll att användas som bas för den genererade
symbolfilen. Du kan använda den här funktionen för att uppdatera en
symbolfil så att den motsvarar en nyare uppströmsversion av ditt bibliotek.
.TP 
\fB\-t\fP
Skriv symbolfilen i mall\-läge istället för i formatet kompatibelt med
\fIdeb\-symbols(5)\fP. Huvudskillnaden är att symbolnamn och taggar skrivs i sin
originalform i mall\-läget, till skillnad från de efterbehandlade
symbolnamnen med borttagna taggar som skrivs i det kompatibla
läget. Dessutom kan vissa symboler uteslutas när en vanlig
\fIdeb\-symbols(5)\fP\-fil skrivs (i enlighet med tagghanteringsreglerna) medan
alla symboler alltid skrivs till symbolfilsmallen.
.TP 
\fB\-c\fP\fI[0\-4]\fP
Definiera vilka kontroller som skall utföras när den genererade symbolfilen
jämförs med den mallfil som används som startpunkt. Som standard är nivån
1. Genom att öka nivån utförs flera kontroller, inklusive alla kontroller på
lägre nivå. Nivå 2 misslyckas om nya symboler har introducerats. Nivå 3
misslyckas om några bibliotek har försvunnit. Nivå 4 misslyckas om några
bibliotek har introducerats.

Värdet kan överstyras med miljövariabeln DPKG_GENSYMBOLS_CHECK_LEVEL.
.TP 
\fB\-q\fP
Håll tyst och generera aldrig en differens mellan den genererade symbolfilen
och mallfilen som användes som startpunkt eller visa varningar om
nya/förlorade bibliotek eller nya/förlorade symboler. Den här flaggan tar
endast bort informationsutdata, inte själva kontrolleran (se flaggan \fI\-c\fP).
.TP 
\fB\-a\fP\fIarkitektur\fP
Anta \fIarkitektur\fP som värdarkitektur vid hantering av symbolfiler. Använd
den här flaggan för att generera en symbolfil eller differens för valfri
arkitektur så länge dess binärer är tillgängliga.
.TP 
\fB\-d\fP
Aktiverar felsökningsläge. Flera meddelanden visas för att förklara vad
\fBdpkg\-gensymbols\fP gör.
.TP 
\fB\-V\fP
Aktivera pratsamt läge. Den genererade symbolfilen innehåller ej längre
rekommenderade symboler som kommentarer. I mall\-läge följs dessutom
mönstersymboler av kommentarer som visar vilka verkliga symboler som har
träffats av mönstret.
.TP 
\fB\-h\fP, \fB\-\-help\fP
Visar hjälpskärm och avslutar.
.TP 
\fB\-\-version\fP
Visar version och avslutar.
.
.SH "SE ÄVEN"
\fBhttp://people.redhat.com/drepper/symbol\-versioning\fP
.br
\fBhttp://people.redhat.com/drepper/goodpractice.pdf\fP
.br
\fBhttp://people.redhat.com/drepper/dsohowto.pdf\fP
.br
\fBdeb\-symbols\fP(5), \fBdpkg\-shlibdeps\fP(1).
.
.SH FÖRFATTARE
Upphovsrättsskyddat © 2007\-2009 Raphaël Hertzog
.sp
Detta är fri programvara; se GNU General Public License version 2 eller
senare för kopieringsvillkor. Det finns INGEN GARANTI.
.SH "ÖVERSÄTTNING"
Peter Krefting och Daniel Nylander.