diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
commit | b86570f63e533abcbcb97c2572e0e5732a96307b (patch) | |
tree | cabc83be691530ae685c45a8bc7620ccc0e1ebdf /man/sv/deb-src-symbols.pod | |
parent | Initial commit. (diff) | |
download | dpkg-upstream.tar.xz dpkg-upstream.zip |
Adding upstream version 1.20.13.upstream/1.20.13upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r-- | man/sv/deb-src-symbols.pod | 378 |
1 files changed, 378 insertions, 0 deletions
diff --git a/man/sv/deb-src-symbols.pod b/man/sv/deb-src-symbols.pod new file mode 100644 index 0000000..597c8a5 --- /dev/null +++ b/man/sv/deb-src-symbols.pod @@ -0,0 +1,378 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NAMN + +deb-src-symbols - Debians utökade mallfil för delade bibliotek + +=head1 SYNOPS + +B<debian/>I<paket>B<.symbols.>I<ark>, B<debian/symbols.>I<ark>, +B<debian/>I<paket>B<.symbols>, B<debian/symbols> + +=head1 BESKRIVNING + +Symbolfilmallar medföljer Debiankällkodspaket och dess format är en +övermängd av symbols-filen som sänds med Debianbinärpaket, se +L<deb-symbols(5)>. + +=head2 Kommentarer + +Kommentarer stöds i symbolmallfilerna. Alla rader med ”#” som första tecken +är kommentarer, såvida inte det börjar med ”#include” (se stycket B<Använda +inkluderingar>). Rader som börjar med ”#MISSING:” är speciella kommentarer +som dokumenterar symboler som har försvunnit. + +=head2 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 I<#PACKAGE#>. Den ersätts av det faktiska +paketnamnet när symbolfilen installeras. Till skillnad från +I<#MINVER#>-markören kommer I<#PACKAGE#> aldrig att dyka upp i en symbolfil +i ett binärpaket. + +=head2 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 B<dpkg-gensymbols> och som utlöser specialhantering av +symbolerna. Se undersymbolen B<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 B<(>, slutar med en högerparentes B<)>, +och måste innehålla minst en tagg. Ytterligare taggar avdelas med tecknet +B<|>. En tagg kan ha ett värde, vilket separeras från taggnamnet med tecknet +B<=>. Taggnamn och värden kan vara godtyckliga strängar, förutom att de inte +kan innehålla de speciella tecknen B<)> B<|> B<=>. Symbolnamn som följer en +taggangivelse kan, om så önskas, citeras med antingen B<'> eller B<"> 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"@Base 1.0 + (optional)taggad_ociterad_symbol@Base 1.0 1 + otaggad_symbol@Base 1.0 + +Den första symbolen i exemplet är heter I<taggad citerad symbol> och har två +taggar: I<tag1> med värdet I<jag är markerad> och I<taggnamn med blanksteg> +som inte har något värde. Den andra symbolen heter I<taggad_ociterad_symbol> +och är bara taggad med taggen som heter I<optional>. Den sista symbolen är +ett exempel på en normal, otaggad symbol. + +Eftersom symboltaggar er en utökning av formatet i 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 B<dpkg-gensymbols> anropas utan flaggan B<-t> kommer det +att mata ut symbolfiler kompatibla med B<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 (B<-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. + +=head2 Standardsymboltaggar + +=over + +=item B<optional> + +En symbol markerad som valfri (optional) kan försvinna från bibliotektet när +som helst och kommer aldrig göra så att B<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. + +=item B<arch=>I<arkitekturlista> + +=item B<arch-bits=>I<arkitekturlista> + +=item B<arch-endian=>I<arkitektur-byteordning> + +Dessaa taggar gör det möjligt att begränsa vilken uppsättning arkitekturer +symbolen är tänkt att finnas för. Taggarna B<arch-bits> och B<arch-endian> +stöds sedan dpkg 1.18.0. 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å B<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 eller inte motsvarar +byteordningen eller antal bitar), görs den arkitekturneutral (dvs. taggarna +arch, arch-bits och arch-endgian 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å I<arkitekturlista> är detsamma som det som används i +B<Build-Depends>-fältet i 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, valfri-amd64, ia64, den +andra bara på linux-arkitekturer medan den tredje tas med överallt förutom +på armel. + + (arch=alpha any-amd64 ia64)64bitarsspecifik_symbol@Base 1.0 + (arch=linux-any)linuxspecifik_symbol@Base 1.0 + (arch=!armel)symbol_armel_inte_har@Base 1.0 +I<architecture-bits> är antingen B<32> eller B<64>. + + (arch-bits=32)32bitarsspecifik_symbol@Base 1.0 + (arch-bits=64)64bitarsspecifik_symbol@Base 1.0 + +I<architecture-byteordning> är antingen B<little> eller B<big>. + + (arch-endian=little)little_endianspecifik_symbol@Base 1.0 + (arch-endian=big)big_endianspecifik_symbol@Base 1.0 + +Flera begränsningar kan kedjas samman + + (arch-bits=32|arch-endian=little)32bitars_le_symbol@Base 1.0 + +=item B<allow-internal> + +dpkg-gensymbols har en intern svartlista över symboler som inte ska +förekomma i symbolfiler eftersom de oftast bara är sidoeffekter från +implementationsdetaljer i verktygskedjan (sedan dpkg 1.20.1). Om du, av +någon orsak, verkligen vill att en av dessa symboler ska tas med i +symbolfilen måste du tagga symbolen med B<allow-internal>. Det kan vara +nödvändigt för lågnivå-verktygskedjebibliotek som ”libgcc”. + +=item B<ignore-blacklist> + +Ett alias för B<allow-internal> som avråds från (sedan dpkg 1.20.1, stöds +sedan dpkg 1.15.3). + +=item B<c++> + +Betecknar I<c++>-symbolmönster. Se stycket B<Använda symbolmönster> nedan. + +=item B<symver> + +Anger I<symver> (symbolversion)-symbolmönstret. Se stycket B<Använda +symbolmönster> nedan. + +=item B<regex> + +Anger I<regex>-symbolmönstret. Se stycket I<Använda symbolmönster> nedan. + +=back + +=head2 Använda symbolmönster + +Till skillnad från vanliga symbolspecifikationer kan ett mönster täcka flera +faktiska symboler från biblioteket. B<dpkg-gensymbols> kommer försöka matcha +varje mönster mot varje faktisk symbol som I<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å B<dpkg-genchanges> att misslyckas +om B<-c1> eller högre anges. Om ett sådant misslyckande inte är önskvärt kan +mönstret dock märkas med taggen I<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 I<arch>-taggen. Se stycket +B<Standardsymboltaggar> ovan för mer information. + +Mönster är en utökning av B<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 ska jämföras mot I<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 B<dpkg-gensymbols> tre grundläggande mönstertyper: + +=over + +=item B<c++> + +Detta mönster anges med taggen I<c++>. Den matchar enbart C++-symboler med +deras avmanglade symbolnamn (som det skrivs ut av +B<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 +I<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 I<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. + +=item B<symver> + +Detta mönster anges med taggen I<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 +I<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. + +=item B<regex> + +Mönster med reguljära uttryck anges med taggen I<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 I<^>, annars kommer det matcha godtycklig del av den verkliga +symbolens I<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 I<optional>-taggen från mönstret. + +=back + +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 I<c++> +och I<symver>) och generella mönster (I<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 +I<c++>, sedan I<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å B<dpkg-gensymbols> genererar differensfiler +baserad på den alfanumeriska sorteringsordningen av dess namn. + +=head2 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: + +=over + +=item * + +Du kan faktorisera de gemensamma delarna i en extern fil och inkludera den +filen i din I<paket>.symbols.I<arkitektur>-fil genom att använda ett +inkluderingsdirektiv som detta: + + #include "I<paket>.symbols.common" + +=item * + +Inkluderingsdirektivet kan även taggas som alla andra symboler: + + (tagg|...|taggN)#include "fil-att-inkludera" + +Alla symboler som inkluderas från I<fil-att-inkludera> kommer att anses som +standard vara taggade med I<tagg> ... I<taggN>. Du kan använda denna +funktion för att skapa en gemensam I<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 + +=back + +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 SONAME:t 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 +=head1 SE ÄVEN + +B<deb-symbols>(5), B<dpkg-shlibdeps>(1), B<dpkg-gensymbols>(1). + + +=head1 ÖVERSÄTTNING + +Peter Krefting och Daniel Nylander. |