Provided by: dpkg-dev_1.16.1.2ubuntu7_all bug

NAMN

       dpkg-gensymbols - generera symbolfiler (information om delade bibliotek)

SYNOPS

       dpkg-gensymbols [flagga...]

BESKRIVNING

       dpkg-gensymbols  söker  genom  en  temporärt  byggträd  (som  standard  debian/tmp)  efter
       bibliotek och skapar en symbols-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.

       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):

       ·   debian/paket.symbols.arkitektur

       ·   debian/symbols.arkitektur

       ·   debian/paket.symbols

       ·   debian/symbols

       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 dpkg-gensymbols kan hjälpa till.

       När  den  genererade  symbolfilen  skiljer  sig mot den version som tillhandahållits av de
       paketansvariga  kommer  dpkg-gensymbols  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 -c).

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/paket. 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.

       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.

       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  Använda
       inkluderingar). Rader som börjar med "#MISSING:" är speciella kommentarer som dokumenterar
       symboler som har försvunnit.

   Använda #PACKAGE#-substituering
       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 #PACKAGE#.
       Den ersätts av det faktiska paketnamnet när symbolfilen installeras.  Till  skillnad  från
       #MINVER#-markören kommer #PACKAGE# aldrig att dyka upp i en symbolfil i ett binärpaket.

   Använda symboltaggar
       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 dpkg-gensymbols och som utlöser
       specialhantering av symbolerna. Se undersymbolen Standardsymboltaggar för mer  information
       om dessa taggar.

       Taggarna anges precis före symbolnamnet (inga blanksteg tillåts mellan). Den börjar alltid
       med en vänsterparentes (, slutar med en högerparentes ),  och  måste  innehålla  minst  en
       tagg. Ytterligare taggar avdelas med tecknet |. En tagg kan ha ett värde, vilket separeras
       från taggnamnet med tecknet =. Taggnamn och värden kan vara godtyckliga strängar,  förutom
       att  de  inte  kan  innehålla  de  speciella  tecknen  )  |  =.  Symbolnamn  som följer en
       taggangivelse kan, om så önskas, citeras med antingen ' eller " 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.

        (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

       Den första symbolen i exemplet är heter taggad citerad symbol och har två taggar: tag1 med
       värdet  jag  är  markerad  och  taggnamn med blanksteg som inte har något värde. Den andra
       symbolen heter taggad_ociterad_symbol och är bara taggad med taggen  som  heter  optional.
       Den sista symbolen är ett exempel på en normal, otaggad symbol.

       Eftersom  symboltaggar  er en utökning av formatet i deb-symbols(5) 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  dpkg-gensymbols anropas utan flaggan -t
       kommer det att mata ut symbolfiler kompatibla med  deb-symbols(5)-formatet:  det  hanterar
       symboler  helt  beroende  på vad som beskrivs av standardtaggarna och tar bort alla taggar
       från utdata. I mall-läge (-t) 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.

   Standardsymboltaggar
       optional
              En  symbol  markerad  som valfri (optional) kan försvinna från bibliotektet när som
              helst och kommer aldrig göra så att dpkg-gensymbols 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.

       arch=arkitekturlista
              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å dpkg-gensymbols 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å arkitekturlista är detsamma som det som används i Build-Depends-fältet
              i debian/control (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

       ignore-blacklist
              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 ignore-blacklist.  Det  kan
              vara nödvändigt för lågnivå-verktygskedjebibliotek som libgcc.

       c++    Betecknar c++-symbolmönster. Se stycket Använda symbolmönster nedan.

       symver Anger  symver  (symbolversion)-symbolmönstret.  Se  stycket  Använda  symbolmönster
              nedan.

       regex  Anger regex-symbolmönstret. Se stycket Använda symbolmönster nedan.

   Använda symbolmönster
       Till skillnad från vanliga symbolspecifikationer kan  ett  mönster  täcka  flera  faktiska
       symboler  från  biblioteket. dpkg-gensymbols kommer försöka matcha varje mönster mot varje
       faktisk symbol som inte 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å dpkg-genchanges att misslyckas om -c1 eller högre anges.  Om  ett
       sådant  misslyckande  inte  är  önskvärt  kan mönstret dock märkas med taggen optional. 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  arch-taggen.  Se  stycket  Standardsymboltaggar  ovan  för  mer
       information.

       Mönster  är  en  utökning  av  deb-symbols(5)-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 namn@version 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 dpkg-gensymbols tre grundläggande mönstertyper:

       c++
          Detta  mönster  anges  med  taggen  c++.  Den  matchar  enbart  C++-symboler  med deras
          avmanglade symbolnamn (som det skrivs ut av c++filt(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
          icke-virtuella  "thunks"  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
          c++-mönster:

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

          Det avmanglade namnet ovan kan hämtas genom att utföra följande kommando:

           $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt

          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.

       symver
          Detta  mönster  anges med taggen symver. 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 symver-möster för att matcha alla symboler som matchar den
          specifika versionen. Till exempel:

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

          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.

          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.

       regex
          Mönster  med  reguljära  uttryck  anges  med taggen regex. 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 ^, annars kommer det matcha
          godtycklig del av den verkliga symbolens namn@version-sträng. Till exempel:

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

          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 optional-taggen från mönstret.

       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

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

       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\dEi@Base"
       inte att träffas av något av mönstrena eftersom det inte är en giltig C++-symbol.

       I  allmänhet delas alla mönster in i två grupper. alias (grundläggande c++ och symver) och
       generella mönster (regex, 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.

       När  flera  mönster träffar samma verkliga symbol föredras alias (först c++, sedan symver)
       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å  dpkg-gensymbols  genererar
       differensfiler baserad på den alfanumeriska sorteringsordningen av dess namn.

   Använda inkluderingar
       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:

       ·   Du kan faktorisera de gemensamma delarna i en extern fil och inkludera den filen i din
           paket.symbols.arkitektur-fil genom att använda ett inkluderingsdirektiv som detta:

           #include "paket.symbols.common"

       ·   Inkluderingsdirektivet kan även taggas som alla andra symboler:

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

           Alla symboler som inkluderas från fil-att-inkludera kommer att anses som standard vara
           taggade  med  tag  ..  tagN.  Du  kan använda denna funktion för att skapa en gemensam
           paket.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

       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.

       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:

       #include "libnågonting1.symbols.common"
        arkitekturspecifik_symbol@Base 1.0

   God hantering av bibliotek
       Ett välunderhållet bibliotek har följande funktioner:

       ·   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;

       ·   ideellt  använder det en versionhanterade symboler för att upprätthålla ABI-stabilitet
           trots interna ändringar och API-utökningar;

       ·   det exporterar inte privata symboler (sådana symboler kan taggas  med  "optional"  för
           att gå runt detta).

       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.

FLAGGOR

       -Ppaketbyggkatalog
              Sök paketbyggkatalog istället för debian/tmp.

       -ppaket
              Definiera paketnamnet. Krävs om mer  än  ett  binärpaket  listas  i  debian/control
              (eller om det inte finns någon debian/control-fil).

       -vversion
              Definiera    paketversion.    Standardvärdet   är   versionen   som   hämtas   från
              debian/changelog. Krävs om programmet anropas utanför ett källkodspaketträd.

       -ebiblioteksfil
              Analyserar endast bibliotek som  listats  explicit  istället  för  att  hitta  alla
              publika  bibliotek.  Du  kan  använda ett reguljärt uttryck i biblioteksfil för att
              träffa multipla bibliotek med ett enda argument (annars behöver du flera -e).

       -Ifilnamn
              Använd filnamn som referensfil för att generera symbolfilen som integreras i själva
              paketet.

       -O     Skriv  den  genererade  symbolfilen  på  standard ut, i stället för att lagra den i
              paketets byggträd.

       -Ofilnamn
              Lagra den genererade symbolfilen som filnamn. Om  filnamn  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.

       -t     Skriv   symbolfilen   i   mall-läge   istället   för  i  formatet  kompatibelt  med
              deb-symbols(5).  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   deb-symbols(5)-fil   skrivs   (i   enlighet   med
              tagghanteringsreglerna) medan alla symboler alltid skrivs till symbolfilsmallen.

       -c[0-4]
              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.

       -q     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 -c).

       -aarkitektur
              Anta  arkitektur  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.

       -d     Aktiverar   felsökningsläge.   Flera   meddelanden   visas  för  att  förklara  vad
              dpkg-gensymbols gör.

       -V     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.

       -h, --help
              Visar hjälpskärm och avslutar.

       --version
              Visar version och avslutar.

SE ÄVEN

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

FÖRFATTARE

       Upphovsrättsskyddat © 2007-2009 Raphaël Hertzog

       Detta är fri programvara; se GNU  General  Public  License  version  2  eller  senare  för
       kopieringsvillkor. Det finns INGEN GARANTI.

ÖVERSÄTTNING

       Peter Krefting och Daniel Nylander.