Kummalisel kombel on kompilaatorid üks väheseid UNIX-i rakendusi, mis hoolib faililaienditest. Laiendusena määrab GCC, milline fail on selle ees ja mida sellega teha (teha) saab. Keele lähtefailid C peab olema keeles .c laiend C ++valikuliselt .cpp, päisefailid keeles C .h, .o objektifailid ja nii edasi. Kui kasutate valet laiendit, gcc ei tööta õigesti (kui olete üldse nõus, siis tehke midagi).

Liigume edasi praktika juurde. Kirjutame, koostame ja käivitame mõne lihtsa programmi. Me ei ole originaalsed, kuna selles keeles on näidisprogrammi lähtefail C Loome järgmise sisuga faili:

/ * tere.c * /

# kaasata

Peamine ( tühine )
{

Printf ("Tere maailm \\ n");

tagasi 0 ;

Nüüd väljastage kataloogis c hello.c käsk:

$ gcc hello.c

Mõne sekundi murdosa järel ilmub kataloogi a.out-fail:

$ ls
a.out tere.c

See on meie programmi valmis käivitatav fail. Vaikimisi gcc annab väljundile käivitatava nime a.out (ükskord see nimi tähendas monteerija väljund).

$ fail a.out
a.out: ELF-i 64-bitine käivitatav LSB, x86-64, versioon 1 (SYSV), dünaamiliselt lingitud (kasutab jagatud libisid), GNU / Linux 2.6.15 jaoks, ilma ribadeta

Laske tulemuseks saadud tarkvara:

$ ./a.out
Tere, Maailm

Miks on vaja käsuga faili asukoht selgesõnaliselt määrata, et käivitada fail praegusest kataloogist? Kui käivitatava faili asukohta pole selgesõnaliselt täpsustatud, otsib käske tõlgendav kest faili süsteemimuutuja PATH loetletud kataloogides.

$ echo $ PATH
/ usr / kohalik / sbin: / usr / kohalik / bin: / usr / sbin: / usr / bin: / sbin: / bin: / usr / mängud

Loendis olevad kataloogid eraldatakse koolonitähisega. Faile otsides vaatab kest katalooge kataloogide järjekorras. Vaikimisi on turvalisuse tagamiseks praegune kataloog. ei sisaldu loendis, nii et kest ei otsi selles käivitatavaid faile.

Miks ei soovitata teha. PATHIS? Usutakse, et reaalses mitmekasutajasüsteemis leidub alati mõni paha inimene, kes paigutab avalikku kataloogi pahatahtliku programmi, mille nimi on käivitatava faili nimi, mis langeb kokku mõne käsu nimega, mida kohalik superhalduri õigustega kohalik administraator sageli kutsub ... vandenõu õnnestub, kui. on kataloogide nimekirja alguses.

Utiliit faili kuvab teabe faili käsurida üle kantud tüübi kohta (süsteemi seisukohast), mõne tüüpi failide korral kuvatakse faili sisu kohta lisateave.

$ fail hello.c
hello.c: ASCII C programmi tekst
$ fail annotation.doc
annotation.doc: CDF V2 dokument, väike Endian, Os: Windows, versioon 5.1, koodileht: 1251, autor: MIH, mall: Normal.dot, viimati salvestanud: MIH, versiooni number: 83, rakenduse loomise nimi: Microsoft Kontorisõna, kogu redigeerimise aeg: 09:37:00, viimati trükitud: teisipäeval 22. jaanuaril 07:31:00 2009, loomise kellaaeg / kuupäev: esmaspäeval 12. jaanuaril 07:36:00 2009, viimane salvestatud aeg / kuupäev: teisipäeval, 22. jaanuaril 07:34:00 2009, lehekülgede arv: 1, sõnade arv: 3094, märkide arv: 17637, turvalisus: 0

See on tegelikult kõik, mida kasutajalt eduka rakenduse jaoks nõutakse. gcc :)

Väljundfaili nimi (nagu ka kõigi muude loodud failide nimed) gcc) saab muuta valikud -o:

$ gcc -o tere hello.c
$ ls
tere tere.c
$ ./hello
Tere, Maailm

Meie näites tagastab funktsioon pea () näiliselt tarbetu väärtuse 0. UNIX-ilaadsetes süsteemides on tavapärane, et pärast programmi lõpetamist tagastatakse kestale täisarv - , kui see õnnestub, muu - muidu. Kestitõlk omistab saadud väärtuse automaatselt keskkonnamuutujale nimega? ... Selle sisu saate vaadata echo $? :

$ ./hello
Tere, Maailm
$ kaja $?
0

Seda öeldi eespool gcc see on juhtimisprogramm, mis on loodud kompileerimise protsessi automatiseerimiseks. Vaatame, mis tegelikult juhtub käsu gcc hello.c täitmise tagajärjel.

Kompileerimise protsessi saab jagada 4 põhietappi: eeltöötlus, ise koostamine, kokkupanek, sidumine (ühendamine).

Valikud gcc mis tahes etapis saate protsessi katkestada.

Eeltöötleja valmistab lähtetekstifaili kompileerimiseks ette - lõikab kommentaarid välja, lisab päisefailide sisu (eeltöötluse direktiiv #include), rakendab makrode laiendamist (sümboolsed konstandid, eeltöötluse direktiiv #defineeri).

Kasutades ära variant -E järgmised sammud gcc saate eeltöötleja töödeldud faili sisu katkestada ja seda vaadata.

$ gcc -E -o hello.i hello.c
$ ls
tere.c tere.i
$ vähem tere.i
. . .
# 1 "/usr/include/stdio.h" 1 3 4
# 28 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
. . .
typedef allkirjastamata char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
. . .
extern int printf (__kontrolli täht * __ piira __vormingut, ...);
. . .
# 4 "hello.c" 2
peamine (tühine)
{
printf ("Tere maailm \\ n");
tagasi 0;
}

Pärast eeltöötleja poolt töötlemist paisus meie programmi lähtekood üles ja sai loetamatu vormi. Kood, mille me kunagi oma kätega kirjutasime, keelas faili lõpus mõne rea alla. Põhjus - kaasa arvatud standardse teegi päisefail C... Päisefail stdio.h sisaldab palju erinevaid asju ja nõuab ka muude päisefailide kaasamist.

Pange tähele faili hello.i laiendamist. Kokkulepete järgi gcc laiend .i vastab keele lähtefailidele C ei vaja eeltöötlemist. Sellised failid kompileeritakse eeltöötlejast mööda minnes:

$ gcc -o tere hello.i
$ ls
tere tere.c tere.i
$ ./hello
Tere, Maailm

Pärast eeltöötlust on käes kompileerimise kord. Kompilaator teisendab kõrgetasemelise programmi lähtekoodi koostikeele koodiks.

Sõna koostamise tähendus on udune. Näiteks vikipeedikud usuvad, viidates rahvusvahelised standardidsee kompileerimine on "kõrgetasemelises programmeerimiskeeles kirjutatud programmi lähteteksti teisendamine kompilaatori abil masinale lähedaseks keeleks või objektkoodiks". Põhimõtteliselt sobib see määratlus meile, montaažikeel on tõesti masinakeelele lähemal kui C... Kuid igapäevaelus mõistetakse kompileerimist enamasti lihtsalt mis tahes toiminguna, mis teisendab mis tahes programmeerimiskeeles oleva programmi lähtekoodi käivitatavaks koodiks. See tähendab, et protsessi, mis hõlmab kõiki nelja ülaltoodud etappi, võib nimetada ka kompileerimiseks. Selles tekstis on sarnane kahemõttelisus. Teisest küljest võib programmi lähtekoodi teisendamise keelekoodiks teisendamise toimingut tähistada ka sõnatõlkega - "ühes programmeerimiskeeles esitatud programmi teisendamine teises keeles programmiks ja teatud mõttes samaväärseks esimese keelega".

Pärast kompilatsiooni lõpuleviimist käivitatava faili loomise protsessi saate peatada variant -S:

$ gcc -S hello.c
$ ls
tere.c tere.s
$ fail hello.s
tere.s: ASCII koostaja programmi tekst
$ vähem tere.s
.fail "tere.c"
.sektsioon .andmed
.LC0:
.string "Tere maailm"
.tekst
.globl peamine
.tüüp peamine, @funktsioon
peamine:
pushl% ebp
movl% esp,% ebp
andl -16 dollarit,% esp
subl 16 dollarit,% esp
movl $ .LC0, (% esp)
kõne paneb
movl $ 0,% eax
lahkuda
ret
.suurus peamine, .- peamine

Fail hello.s ilmus kataloogi, mis sisaldab programmi rakendamist koostekeeles. Pange tähele, et väljundfaili nime täpsustamine nupuga valikud -o sel juhul seda ei nõutud, gcc genereeris selle automaatselt, asendades .c laiend algse failinimega .s Enamiku põhitoimingute jaoks gcc väljundfaili nimi moodustatakse sarnase asendamisega. Laiend .s on komplekteerimiskeelsete lähtefailide standard.

Muidugi võite käivitatava koodi hankida ka failist hello.s:

$ gcc -o hello hello.s
$ ls
tere tere.c tere.s
$ ./hello
Tere, Maailm

Monteerimistoimingu järgmine etapp on montaažikeele koodi tõlkimine masinkoodiks. Operatsiooni tulemus on objektfail. Objektifail sisaldab täitmiseks valmis masinkoodi plokke, andmeplokke, samuti failis määratletud funktsioonide ja väliste muutujate loendit ( sümbolitabel ), kuid see ei täpsusta funktsiooni ja andmeviidete absoluutseid aadresse. Objektifaili ei saa käivitamiseks otse täitmiseks, kuid hiljem (ühendamise etapis) saab seda kombineerida teiste objektide failidega (sel juhul arvutatakse sümbolitabelite kohaselt ristviidete failide vahel olevad aadressid ja need täidetakse). Võimalus gcc -c, peatab protsessi monteerimisfaasi lõpus:

$ gcc -c hello.c
$ ls
tere.c tere.o
$ fail hello.o
tere.o: ELF 64-bitine LSB ümberpaigutatav, x86-64, versioon 1 (SYSV), eemaldamata

Objektifailide standardlaiend on .o.

Kui tulemuseks olev objektfail hello.o antakse linkerile, arvutab viimane linkide aadressid, lisab programmi käivitamise ja lõpetamise koodi, raamatukogu funktsioonide väljakutsumise koodi ja selle tulemusel on meil programmi valmis käivitatav fail.

$ gcc -o tere hello.o
$ ls
tere tere.c tere.o
$ ./hello
Tere, Maailm

Mida me oleme nüüd teinud (või õigemini gcc tegi seda meie eest) ja seal on viimase etapi sisu - linkimine (linkimine, linkimine).

Noh, see seisneb kompileerimises ja ongi. Nüüd puudutame mõnda minu arvates olulist varianti gcc.

Variant -I tee / kataloog / kataloog / koos päiste / failidega - lisab määratud kataloogi päisefailide otsinguteede loendisse. Valiku lisatud kataloog -Mina kõigepealt otsiti, seejärel jätkub otsing tavapärastes süsteemikataloogides. Kui valikud -Mina skaneeritakse mitu nende poolt määratud kataloogi vasakult paremale, kui valikud ilmuvad.

Valik -Sein - kuvab koodis võimalike tõrgete põhjustatud hoiatused, mis ei takista programmi kompileerimist, kuid mis võib kompilaatori arvates selle täitmisel tekitada teatavaid probleeme. Oluline ja kasulik võimalus, arendajad gcc soovitage seda alati kasutada. Näiteks antakse järgmise faili kompileerimisel palju hoiatusi:

1 / * remark.c * /
2
3 staatiline int k \u003d 0;
4 staatiline int l ( int a);
5
6 peamist ()
7 {
8
9 int a;
10
11 int b, c;
12
13 b + 1;
14
15 b \u003d c;
16
17 int * p;
18
19 b \u003d * p;
20
21 }

$ gcc -o märkus remark.c
$ gcc -Wall - märkuse remark.c lisamine
remark.c: 7: hoiatus: tagasitüübi vaikeseadeks on int

remark.c: 13: hoiatus: avaldus, millel puudub mõju
remark.c: 9: hoiatus: kasutamata muutuja 'a'
remark.c: 21: hoiatus: kontroll jõuab tühja funktsiooni lõppu
remark.c: tipptasemel:
remark.c: 3: hoiatus: 'k' on määratletud, kuid mitte kasutatud
remark.c: 4: hoiatus: „l” kuulutatakse staatiliseks, kuid pole kunagi määratletud
remark.c: funktsioonis „main”:
remark.c: 15: hoiatus: selles funktsioonis kasutatakse tähist c initsialiseerimata
remark.c: 19: hoiatus: selles funktsioonis kasutatakse algatuseta tähist p

Valik - viga - muudab kõik hoiatused vigadeks. Hoiatuse ilmumisel katkestab koostamisprotsessi. Kasutatakse koos variant -Sein.

$ gcc -Werror -o märkus remark.c
$ gcc -Werror -Wall -o remark.c märkuse lisamine
cc1: hoiatusi käsitletakse vigadena
remark.c: 7: tõrge: tagastamise tüüp vaikimisi väärtus "int"
remark.c: funktsioonis „main”:
remark.c: 13: viga: avaldus, millel pole mõju
remark.c: 9: tõrge: kasutamata muutuja 'a'

Valik -g - paigutab siluri tööks vajaliku teabe objekti või käivitatavasse faili gdb... Järgnevaks silumiseks projekti koostamisel variant -g tuleb lisada nii kompileerimise ajal kui ka linkimise ajal.

Valikud -O1, -O2, -O3 - määrake kompilaatori loodud koodi optimeerimise tase. Arvu kasvades optimeerimise aste suureneb. Valikute toimimist saab näha sellest näitest.

Algne fail:

/ * ring.c * /

Peamine ( tühine )
{

int i;

jaoks (i \u003d 0; i< 10 ; ++i)
;

tagasi i;

Kompileerimine vaikimisi optimeerimise tasemega:

$ gcc -S ring.c
$ vähem ringi.s
.fail "ring.c"
.tekst
.globl peamine
.tüüp peamine, @funktsioon
peamine:
pushl% ebp
movl% esp,% ebp
subl 16 dollarit,% esp
movl 0 dollarit, -4 (% ebp)
jmp .L2
.L3:
addl $ 1, -4 (% ebp)
.L2:
cmpl 9 dollarit, -4 (% ebp)
jle .L3
movl -4 (% ebp),% eax
lahkuda
ret
.suurus peamine, .- peamine
.ident "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
.sektsioon .note.GNU-stack, "", @ progbits

Kompileerimine maksimaalse optimeerimistasemega:

$ gcc -S -O3 ring.c
$ vähem ringi.s
.fail "ring.c"
.tekst
.p2joon 4.15
.globl peamine
.tüüp peamine, @funktsioon
peamine:
pushl% ebp
movl 10 dollarit, eax%
movl% esp,% ebp
popl% ebp
ret
.suurus peamine, .- peamine
.ident "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
.sektsioon .note.GNU-stack, "", @ progbits

Teisel juhul puudub saadud koodil isegi vihje ühegi silmuse kohta. I väärtust saab arvutada koostamisetapis, mis tehti.

Paraku pole reaalsete projektide puhul erinevusi optimeerimise erinevatel tasemetel praktiliselt märgatav ...

Variant -00 - tühistab koodi optimeerimise. See suvand on vajalik rakenduse silumise etapis. Nagu ülalpool näidatud, võib optimeerimine viia programmi struktuuris tundmatuseni muutumiseni, käivitatava ja lähtekoodi vaheline seos ei ole selge ja vastavalt sellele pole programmi sammhaaval silumine võimalik. Kui suvand on lubatud -g, on soovitatav lisada ja -O0.

Optsioon -Os - seab optimeerimise mitte koodi tõhususe, vaid saadud faili suuruse järgi. Sel juhul peaks programmi jõudlus olema võrreldav vaikimisi optimeerimistasemega kompileerimise käigus saadud koodi jõudlusega.

Valik -march \u003d arhitektuur - täpsustab sihtprotsessori arhitektuuri. Toetatavate arhitektuuride loend on näiteks protsessorpere jaoks ulatuslik Intel / AMD sa võid küsida i386, pentium, prescott, opteron-sse3 jne. Binaarsete jaotuste kasutajad peaksid meeles pidama, et programmid töötaksid määratud valikuga korrektselt, soovitav, et kõik kaasatud teegid kompileeritaks sama valikuga.

Linkerile edastatud valikuid arutatakse allpool.

Väike lisandus:

Seda öeldi eespool gcc määrab ülekantud failide tüübi (programmeerimiskeele) nende laiendi järgi ja teeb vastavalt arvatavale tüübile (keelele) nendega toiminguid. Kasutaja on kohustatud jälgima loodud failide laiendusi, valides need vastavalt lepingule gcc... Reaalsuses gcc saate libistada suvaliste nimedega faile. Gcc -x variant võimaldab teil täpselt määratleda kompileeritud failide programmeerimiskeele. See suvand kehtib kõigi järgmiste käsus loetletud failide kohta (kuni ilmub järgmine suvand -x). Võimalikud valikuargumendid:

c c-header c-cpp-output

c ++ c ++ - päis c ++ - cpp-output

objektiiv-c eesmärk-c-päis eesmärk-c-cpp-väljund

objektiiv-c ++ eesmärk-c ++ - päis eesmärk-c ++ - cpp-väljund

monteerija monteerija-cpp-ga

ada

f77 f77-cpp-sisend

f95 f95-cpp-sisend

java

Argumentide eesmärk peaks olema selge nende kirjutamisest (siin cpp pole midagi pistmist C ++, see on eeltöötleja poolt eeltöödeldud lähtekoodifail). Kontrollime:

Eraldi koostamine

Keelte tugevus C / C ++ on võimalus jagada programmi lähtekood mitmeks failiks. Veel võib öelda - eraldi kompileerimise võimalus on keele alus, ilma selle tõhusa kasutamiseta C pole mõeldav. See on mitme failiga programmeerimine, mis võimaldab teil seda sisse viia C sellised suured projektid nagu Linux (siin sõna all Linux tähendab nii kernelit kui ka süsteemi tervikuna). Mida annab eraldi kompileerimine programmeerijale?

1. Võimaldab muuta programmi (projekti) koodi loetavamaks. Mitmekümne ekraani lähtefail muutub peaaegu üle jõu. Kui jagate selle vastavalt mõnele (eelmõeldud) loogikale mitmeks väikeseks killuks (igaüks eraldi failina), on projekti keerukusega palju lihtsam toime tulla.

2. Lühendab projekti uuesti kompileerimise aega. Kui muudatused tehakse ühes failis, pole mõtet kogu projekti ümber kompileerida, piisab ainult selle muudetud faili uuesti kompileerimisest.

3. Võimaldab jagada projekti tööd mitme arendaja vahel. Iga programmeerija loob oma projekti osa ja silub seda, kuid igal ajal on võimalik kogu sellest tulenev arendus koguda (ümber ehitada) lõpptooteks.

4. Ilma eraldi kompileerimiseta poleks raamatukogusid. Koodi korduskasutamine ja levitamine veebisaidil C / C ++, ja kood on binaarne, mis võimaldab ühelt poolt pakkuda arendajatele lihtsat mehhanismi selle kaasamiseks oma programmidesse, teiselt poolt varjata nende eest konkreetseid rakenduse üksikasju. Kas projekti kallal töötades tasub alati mõelda ja mitte vajada midagi sellest, mis on millalgi juba tehtud? Võib-olla peaksite osa koodist eelnevalt raamatukoguks valima ja korrastama? Minu arvates lihtsustab selline lähenemine elu oluliselt ja säästab palju aega.

Gccmuidugi toetab eraldi kompileerimist ega nõua kasutajalt mingeid erijuhiseid. Üldiselt on kõik väga lihtne.

Siin on praktiline näide (ehkki väga, väga tinglik).

Lähtekoodi faili komplekt:

/ * main.c * /

# kaasata

# sisaldab "esimene.h"
# sisaldab "teine.h"

int peamine ( tühine )
{

Esimene ();
teine \u200b\u200b();

Printf ("Põhifunktsioon ... \\ n");

tagasi 0 ;

/ * esimene.h * /

tühine esimene ( tühine );

/ * esimene.c * /

# kaasata

# sisaldab "esimene.h"

tühine esimene ( tühine )
{

Printf ("Esimene funktsioon ... \\ n");

/ * teine.h * /

tühine teine \u200b\u200b( tühine );

/ * teine.c * /

# kaasata

# sisaldab "teine.h"

tühine teine \u200b\u200b( tühine )
{

Printf ("Teine funktsioon ... \\ n");

Üldiselt on meil see:

$ ls
esimene.c esimene.h peamine.c teine.c teine.h

Kogu selle majanduse saab koondada ühte käsku:

$ gcc -Wall -o main main.c esimene.c teine.c
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

Ainult see ei anna meile praktiliselt mingeid boonuseid, ja jaotatud mitme faili peale, välja arvatud struktureeritum ja loetavam kood. Sellise koostamise lähenemisviisi korral ilmnevad kõik ülaltoodud eelised:

$ gcc -Wall -c main.c
$ gcc -Wall -c first.c
$ gcc -Wall -c sekund.c
$ ls
esimene.c esimene.h esimene.o main.c main.o teine.c teine.h teine.o
$ gcc -o peamine main.o esimene.o teine.o
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

Mida me teinud oleme? Igast lähtefailist (kompileerimine valikuga -c) sai objekti faili. Seejärel ühendati objektfailid lõplikuks käivitatavaks. Muidugi meeskonnad gcc neid on rohkem, kuid keegi ei kogu projekte käsitsi, selleks on olemas kogujakommunikatsiooniteenused (kõige populaarsemad tegema). Kõik ülaltoodud eraldi kompileerimise eelised ilmnevad kogumisutiliitide abil.

Tekib küsimus: kuidas linker õnnestub objektifaile kokku panna, õigesti arvutades kõnede aadressi? Kuidas ta isegi teab, et fail second.o sisaldab teise () funktsiooni koodi ja faili main.o kood sisaldab selle üleskutset? Selgub, et kõik on lihtne - objektifail sisaldab nn sümbolitabel , sealhulgas mõne koodipositsiooni nimed (funktsioonid ja välised muutujad). Linker skannib iga objektifaili sümbolitabeli, otsib tavalisi (koos sobivate nimedega) positsioone, mille põhjal teeb järeldused kasutatud funktsioonide (või andmeplokkide) koodi tegeliku asukoha kohta ja arvutab vastavalt sellele ümber käivitatavas failis olevad kõneaadressid.

Sümbolitabelit saate vaadata utiliidi abil nm.

USD nm main.o
U kõigepealt
00000000 T peamine
U paneb
U teine
Esiteks $ nm
00000000 T esimene
U paneb
USD nm teine.o
U paneb
00000000 T sekundit

Put-kõne välimust seletatakse standardse teegi funktsiooni printf () kasutamisega, mis kompileerimise ajal muutus put () -ks.

Sümbolitabel pole kirjutatud mitte ainult objektfaili, vaid ka käivitatavasse faili:

$ nm peamine
08049f20 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
080484fc R _IO_stdin_used
w _Jv_RegisterClasses
08049f10 d __CTOR_END__
08049f0c d __CTOR_LIST__
08049f18 D __DTOR_END__
08049f14 d __DTOR_LIST__
08048538 r __FRAME_END__
08049f1c d __JCR_END__
08049f1c d __JCR_LIST__
0804a014 A __bss_start
0804a00c D __data_start
080484b0 t __do_global_ctors_aux
08048360 t __do_global_dtors_aux
0804a010 D __dso_handle
w __gmon_start__
080484aa T __i686.get_pc_thunk.bx
08049f0c d __init_array_end
08049f0c d __init_array_start
08048440 T __libc_csu_fini
08048450 T __libc_csu_init
U [e-posti aadress on kaitstud]@ GLIBC_2.0
0804a014 A _edata
0804a01c A _end
080484dc T _fini
080484f8 R _fp_hw
080482b8 T _init
08048330 T _start
0804a014 b valmis, 7021
0804a00c W data_start
0804a018 b dtor_idx.7023
0804840c T esimene
080483c0 t frame_dummy
080483e4 T peamine
U [e-posti aadress on kaitstud]@ GLIBC_2.0
08048420 T teine

Sümbolitabeli kaasamine käivitatavasse on silumise hõlbustamiseks eriti vajalik. Põhimõtteliselt pole rakenduse käitamiseks tegelikult vaja. Reaalsete programmide käivitatavate failide jaoks, millel on palju funktsioonimääratlusi ja väliseid muutujaid, kasutades hunnikut erinevaid raamatukogusid, muutub sümbolitabel üsna ulatuslikuks. Väljundfaili suuruse vähendamiseks saab selle eemaldada, kasutades valikuga gcc -s.

$ gcc -s -o peamine main.o esimene.o teine.o
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...
$ nm peamine
nm: peamine: sümboliteta

Tuleb märkida, et linkimise ajal linker funktsioonikõne konteksti ei kontrolli, ta ei jälgi ei tagastamisväärtuse tüüpi ega aktsepteeritud parameetrite tüüpi ega arvu (ning tal pole kohta sellist teavet hankida). Kõik kõne valideerimine tuleb teha kompileerimise ajal. Mitme failiga programmeerimise puhul on selleks vaja kasutada keele päisefailide mehhanismi C.

Raamatukogud

Raamatukogu - keeles C, fail, mis sisaldab objekti koodi, mille saab linkimise ajal teegi abil programmiga siduda. Tegelikult on raamatukogu objektide failide kogum, mis on lingitud erilisel viisil.

Raamatukogude eesmärk on pakkuda programmeerijale koodi taaskasutamise standardset mehhanismi, mis on lihtne ja usaldusväärne.

Operatsioonisüsteemi ja rakendustarkvara seisukohast on raamatukogud staatiline ja jagatud (dünaamiline ).

Staatiline raamatukogu kood sisaldub käivitatavas failis viimase linkimisel. Teek osutub failina "juhtmega", teegi kood "ühendatakse" ülejäänud failikoodiga. Staatilisi raamatukogusid kasutav programm muutub iseseisvaks ja seda saab käivitada peaaegu igas sobiva arhitektuuri ja opsüsteemiga arvutis.

Jagatud teegi kood laaditakse ja ühendatakse opsüsteemi poolt programmi koodiga programmi taotlusel selle täitmise ajal. Dünaamiline teegi kood ei sisaldu programmi käivitatavas failis, vaid käivitatavasse faili on lisatud ainult teegi link. Selle tulemusel lakkab jagatud teeke kasutav programm olema autonoomne ja seda saab edukalt käivitada ainult süsteemis, kuhu asjaomased teegid on installitud.

Ühisel raamatukogu paradigmal on kolm olulist eelist:

1. Käivitatava faili maht on oluliselt vähenenud. Süsteemis, mis sisaldab paljusid sama koodi sisaldavaid binaare, pole vaja iga käivitatava koodi koopiat säilitada.

2. Mitme rakenduse kasutatav jagatud teegi kood salvestatakse RAM-i ühes eksemplaris (tegelikult pole kõik nii lihtne ...), mille tulemusel väheneb süsteemi vajadus saadaoleva RAM-i järele.

3. Iga ühise käivitatava faili koodimuudatuste korral pole iga käivitatavat faili vaja uuesti üles ehitada. Dünaamilise teegi koodi muudatused ja parandused kajastuvad automaatselt igas seda kasutavas programmis.

Ilma jagatud teegi paradigmata poleks eelkompileeritud (binaarseid) jaotusi Linux (jah, ükskõik mida ei eksisteerinud). Kujutage ette jaotuse suurust, mille iga binaarne sisaldaks standarditeegi koodi C (ja kõik muud kaasatud raamatukogud). Kujutage vaid ette, mida oleks vaja süsteemi värskendamiseks pärast ühe laialt kasutatava raamatukogu kriitilise haavatavuse kindlakstegemist ...

Nüüd väike praktika.

Kasutame illustreerimiseks eelmise näite lähtefailide komplekti. Esimese () ja teise () funktsiooni koodi (teostuse) paneme omatehtud raamatukokku.

Linuxis võetakse vastu järgmine raamatukogufailide nimetamisskeem (ehkki seda ei täheldata alati) - teegi failinimi algab libi eesliitega, millele järgneb teegi nimi, lõpus laiend .a ( arhiiv ) - staatilise raamatukogu jaoks, .so ( jagatud objekt ) - jagatud (dünaamilise) korral loetletakse pärast laiendamist versiooninumbrid punkti kaudu (ainult dünaamiliste raamatukogude jaoks). Päisefailide kogule vastav nimi (jällegi tavaliselt) koosneb teegi nimest (ilma eesliite ja versioonita) ja laiendist .h. Näiteks: libogg.a, libogg.so.0.7.0, ogg.h.

Esiteks loogem ja kasutage staatilist teeki.

Esimene () ja teine \u200b\u200b() funktsioon koostavad meie libhello teegi sisu. Teekifaili nimi on vastavalt libhello.a. Võrdleme päisefaili hello.h raamatukoguga.

/ * tere.h * /

tühine esimene ( tühine );
tühine teine \u200b\u200b( tühine );

Muidugi, read:

# sisaldab "esimene.h"

# sisaldab "teine.h"

failides main.c, first.c ja second.c on vaja asendada järgmistega:

# sisaldab "tere.h"

Nüüd sisestame järgmise käskude jada:

$ gcc -Wall -c first.c
$ gcc -Wall -c sekund.c
$ ar crs libhello.a esimene.o teine.o
$ fail libhello.a
libhello.a: praegune arhiiv

Nagu juba mainitud, on raamatukogu objektfailide kogum. Kahe esimese käsklusega lõime need objektfailid.

Järgmisena peate linkima objektfailid komplekti. Selleks kasutatakse arhiveerijat ar - utiliit "liimib" mitu faili ühte, tulemuseks olev arhiiv sisaldab iga üksiku faili taastamiseks (väljavõtmiseks) vajalikku teavet (sealhulgas selle omandiõiguse, juurdepääsu, aja atribuudid). Arhiivi sisu mis tahes "tihendamist" või muude salvestatud andmete teisendamist ei teostata.

C arname variant - arhiivi loomine, kui nimega arhiivi ei eksisteeri, luuakse see, vastasel juhul lisatakse failid olemasolevasse arhiivi.

Variant r - seab arhiivi värskendusrežiimi. Kui määratud nimega fail on arhiivis juba olemas, kustutatakse see ja uus fail lisatakse arhiivi lõppu.

Variant s - lisab (värskendab) arhiivi indeksi. Sel juhul on arhiiviindeks tabel, milles iga arhiveeritud failides määratletud sümboolse nime (funktsiooni või andmeploki nime) jaoks on vastav objektifaili nimi seotud. Arhiiviindeks on vajalik raamatukoguga töö kiirendamiseks - vajaliku definitsiooni leidmiseks pole vaja kõigi arhiivifailide sümbolitabelit läbi vaadata, võite minna otse soovitud nime sisaldava faili juurde. Arhiivide registrit saate vaadata juba tuttava utiliidi abil nm kasutades seda valikuga -s (kuvatakse ka kõigi arhiivi objektifailide sümboltabelid):

$ nm -s libhello.a
Arhiivi register:
esimesena esimeses
teine \u200b\u200bsekundis.o

esimene.o:
00000000 T esimene
U paneb

teine.o:
U paneb
00000000 T sekundit

Arhiiviindeksi loomiseks on spetsiaalne utiliit ranlib... Raamatukogu libhello.a oleks võinud luua nii:

$ ar cr libhello.a esimene.o teine.o
$ ranlib libhello.a

Ilma arhiiviindeksita töötab raamatukogu siiski hästi.

Kasutagem nüüd meie teeki:

$ gcc -Wall -c main.c
$
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

Töötab ...

Noh nüüd kommentaarid ... On kaks uut võimalust gcc:

Valiku -l nimi - linkerile edastatud, näitab vajadust ühendada libnameekide teek käivitatava failiga. Ühendamiseks tähendab, et need ja sellised funktsioonid (välised muutujad) on sellises ja sellises teegis määratletud. Meie näites on raamatukogu staatiline, kõik sümboolsed nimed viitavad koodile, mis asub otse käivitatavas failis. Pöörake tähelepanu võimalustele -l teegi nimi on määratletud nimega ilma libli eesliiteta.

Valik -L / tee / kataloog / kataloog / koos / teekidega - linkerile edastatud, määrab lingitud teeke sisaldava kataloogi tee. Meie puhul mõte . , otsib linker kõigepealt teeke praegusest kataloogist, seejärel süsteemis määratletud kataloogidest.

Siinkohal tuleks teha väike märkus. Fakt on see, et paljude võimaluste puhul gcc oluline on nende käsureal kuvamise järjekord. Nii otsib linker koodi, mis vastab failisümbolitabelis täpsustatud nimedele käsureal loetletud raamatukogudes. pärast selle faili nimi. Linker ignoreerib failinime ees loetletud teekide sisu:

$ gcc -Wall -c main.c
$ gcc -o main -L. -lhello main.o
main.o: Funktsioonis "main":
main.c :(. tekst + 0xa): määratlemata viide esimesele
main.c :(. tekst + 0xf): määratlemata viide "teisele"

$ gcc -o peamine main.o -L. -hello
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

See käitumine gcc tulenevalt arendajate soovist pakkuda kasutajale võimalust ühendada faile raamatukogudega erineval viisil, kasutada ristuvaid nimesid ... Minu arvates on parem mitte sellega vaevata. Üldiselt tuleb lingitud teegid loetleda neid viitava faili nime järel.

Teekide asukoha määramiseks süsteemis on alternatiivne viis. Sõltuvalt jaotusest võib keskkonnamuutuja LD_LIBRARY_PATH või LIBRARY_PATH salvestada koolonitega eraldatud kataloogide loendit, milles linker peaks otsima raamatukogusid. Reeglina pole seda muutujat vaikimisi määratletud, kuid selle loomist ei takista miski:

$ echo $ LD_LIBRARY_PATH

/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/../../../../i686-pc-linux-gnu/bin/ld: ei leia -lhello
colle2: ld täitmine väljus tagasitulekukoodiga 1
$ eksport LIBRARY_PATH \u003d.
$ gcc -o main main.o -lhello
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

Keskkonnamuutujatega manipuleerimine on kasulik nii oma raamatukogude loomisel kui ka silumisel, aga ka juhul, kui peate rakendusega ühendama mõne mittestandardse (vananenud, värskendatud, muudetud - üldiselt erinevad jaotuses sisalduvast) jagatud teegi.

Nüüd loome ja kasutame dünaamilist teeki.

Algsete failide komplekt jääb samaks. Sisestame käsud, vaatame, mis juhtus, lugege kommentaare:

$ gcc -Wall -fPIC -c first.c
$ gcc -Wall -fPIC -c second.c
$ gcc-Shared -o libhello.so.2.4.0.5 -Wl, -soname, libhello.so.2 first.o second.o

Mida sa selle tulemusel said?

$ -fail libhello.so.2.4.0.5
libhello.so.2.4.0.5: ELF-i 64-bitine LSB jagatud objekt, x86-64, versioon 1 (SYSV), dünaamiliselt lingitud, eemaldamata

Fail libhello.so.2.4.0.5 on meie jagatud teek. Sellest, kuidas seda kasutada, räägime allpool.

Nüüd kommentaarid:

Funktsioon -fPIC - nõuab objektfailide loomisel kompilaatori genereerimist positsioonist sõltumatu kood (PIC - positsioonist sõltumatu kood ), on selle peamiseks erinevuseks aadresside esitusviis. Fikseeritud (staatiliste) positsioonide täpsustamise asemel arvutatakse kõik aadressid punktis b täpsustatud nihke põhjal globaalne nihetabel (globaalne nihetabel - GOT ). Positsioonist sõltumatu koodivorming võimaldab ühendada käivitatavad moodulid põhiprogrammi koodiga selle laadimise ajal. Sellest lähtuvalt on positsioonist sõltumatu koodi peamine eesmärk dünaamiliste (jagatud) teekide loomine.

Jagatud variant - näitab gccet tulemus ei peaks olema mitte käivitatav fail, vaid jagatud objekt - dünaamiline teek.

Valik -Wl, -nimi, libhello.so.2 - komplektid soname raamatukogud. Sonaamist räägime üksikasjalikult järgmises lõigus. Nüüd arutame selle valiku vormingut. Esmapilgul näib kummaline, et komadega konstrueerimine on ette nähtud kasutaja otseseks suhtlemiseks linkeriga. Kompileerimise ajal gcc kutsub linkerit automaatselt, automaatselt, oma äranägemise järgi, gcc läbib töö edukaks täitmiseks vajalikud võimalused. Kui kasutajal on vaja linkimisprotsessi ise sekkuda, saab ta kasutada spetsiaalset võimalust gcc -Wl, -valik, väärtus1, väärtus2 ...... Mida tähendab linkerile ülekandmine ( -Wl) valik -valik argumentidega väärtus1, väärtus2 jne. Meie puhul anti võimalus linkerile üle -soname argumendiga libhello.so.2.

Nüüd soname kohta. Teekide loomisel ja levitamisel on probleeme ühilduvuse ja versioonikontrolliga. Selleks, et süsteemil, eriti dünaamilisel raamatukogu laaduril, oleks ettekujutus sellest, millist raamatukogu versiooni rakenduse koostamisel kasutati ja mis seetõttu on selle edukaks toimimiseks vajalik, pakuti spetsiaalset identifikaatorit - soname , mis on paigutatud nii teegi enda kui ka rakenduse käivitatavasse faili. Sonüümitunnus on string, mis sisaldab raamatukogu nime, millele on lisatud eesliide lib, dot, laiend, seega jälle punkt ja teegi versiooni üks või kaks (punktiga eraldatud) numbrit - lib name .so. x. y. See tähendab, et soname sobib teegi failinimega versiooninumbri esimese või teise numbrini. Olgu meie raamatukogu käivitatava faili nimi libhello.so.2.4.0.5, siis võib teegi sonaam olla libhello.so.2. Raamatukogu liidese muutmisel tuleb muuta selle soname! Mis tahes koodimuudatustega, mis põhjustavad kokkusobimatuse varasemate väljalasketega, tuleb lisada uus sonaam.

Kuidas see kõik töötab? Oletame, et mõne rakenduse edukaks täitmiseks on vajalik teek nimega tere, oletagem, et süsteemis on üks, raamatukogu faili nimi on libhello.so.2.4.0.5 ja sinna sisse kirjutatud teegi libhello.so.2 nimi. Taotluse koostamise etapis linker vastavalt võimalusele - Tere!, otsib süsteemist faili nimega libhello.so. Reaalses süsteemis on libhello.so sümboolne link saidile libhello.so.2.4.0.5. Olles saanud juurdepääsu teegi failile, loeb linker sinna kirjutatud sonaami väärtuse ja paigutab selle muu hulgas rakenduse käivitatavasse faili. Kui rakendus käivitatakse, saab dünaamiline raamatukogulaadur taotluse lisada raamatukogu koos käivitatavast failist loetud sonaamiga ja proovib süsteemist leida teeki, mille failinimi vastab sonaamile. See tähendab, et laadur proovib leida faili libhello.so.2. Kui süsteem on õigesti konfigureeritud, peaks see sisaldama sümboolset linki libhello.so.2 failile libhello.so.2.4.0.5, laadija pääseb vajalikku teeki ja siis ühendab ta kõhklemata (ja ilma midagi muud kontrollimata) selle rakendusega. Kujutame nüüd ette, et oleme kolinud sel viisil kompileeritud rakenduse teise süsteemi, kus juurutatakse ainult soname libhello.so.1 teegi eelmist versiooni. Programmi käitamise proovimisel ilmneb tõrge, kuna selles süsteemis pole ühtegi faili nimega libhello.so.2.

Seega peab linker pakkumise koostamise etapis pakkuma teegifaili (või teegifaili sümboolse lingi) nimega lib-nimi .so: laadur vajab käitustõmmise ajal faili (või sümboolset linki) nimega lib-nimi .so. x. y. Mida nimi lib nimega .so. x. y peab vastama kasutatava teegi sonaamistringile.

Binaarsete jaotuste korral paigutatakse raamatukogufail libhello.so.2.4.0.5 ja link sellele libhello.so.2 libhello paketti ning link libhello.so, mis on vajalik ainult kompileerimiseks, koos hello.h teegi päisefailiga pakitud libhello-devel paketti (devel pakett sisaldab ka libhello.a teegi staatilise versiooni faili, staatilist teeki saab kasutada, ka ainult kompileerimisetapis). Paketi lahti pakkimisel asuvad kõik loetletud failid ja lingid (va hello.h) ühes kataloogis.

Veendugem, et antud sonaamirida oleks tegelikult meie raamatukogu failis kirjas. Kasutagem mega utiliiti objdump koos võimalusega -p :

$ objdump -p libhello.so.2.4.0.5 | grep SONAME
SONAME libhello.so.2

Utiliit objdump on võimas tööriist, mis võimaldab teil saada põhjalikku teavet objekti või käivitatava faili sisemise sisu (ja seadme) kohta. Umbes mehe leht ütleb seda objdump esiteks on see kasulik programmeerijatele, kes loovad silumis- ja kompileerimisriistu, mitte ei kirjuta lihtsalt suvalisi rakendusprogramme :) Eelkõige koos võimalusega -d see on lahtivõtja. Kasutasime varianti -p - kuvada mitmesugust metafaili objektifaili kohta.

Selles raamatukogu loomise näites järgisime järeleandmatult eraldi kompileerimise põhimõtteid. Muidugi võiks raamatukogu moodustada niimoodi, ühe kõnega gcc:

$ gcc -jagatud -sein -fPIC -o libhello.so.2.4.0.5 -Wl, -nimi, libhello.so.2 esimene.c teine.c

Proovime nüüd kasutada saadud teeki:

$ gcc -Wall -c main.c
$
/ usr / bin / ld: ei leia -hello
colle2: ld tagastab 1 väljumise oleku

Linker vannub. Pidage meeles, mida eespool öeldi sümboolsete linkide kohta. Looge libhello.so ja proovige uuesti:

$ ln -s libhello.so.2.4.0.5 libhello.so
$ gcc -o peamine main.o -L. -lhello -Wl, -rpath ,.

Nüüd on kõik rahul. Käivitame loodud binaari:

Viga ... Laadur kirub, ei leia teeki libhello.so.2. Veendugem, et link saidile libhello.so.2 on tõesti käivitatavas failis kirjas:

$ objdump -p main | grep VAJALIK
VAJALIK libhello.so.2
VAJALIK libc.so.6

$ ln -s libhello.so.2.4.0.5 libhello.so.2
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

See töötas ... Kommenteerib nüüd uusi võimalusi gcc.

Valik -Wl, -patra,. - juba tuttav konstruktsioon, andke võimalus linkerile üle -tee argumendiga . ... Läbi -tee saate programmi käivitatavasse faili kirjutada täiendavaid teid, mööda mida jagatud teegilaadur raamatukogufaile otsib. Meie puhul on tee registreeritud . - teegi failide otsimine algab aktiivsest kataloogist.

$ objdump -p main | grep RPATH
RPATH.

Tänu sellele suvandile pole programmi käivitamisel vaja keskkonnamuutujaid muuta. On selge, et kui teisaldate programmi mõnda teise kataloogi ja proovite seda käivitada, siis teegi faili ei leita ja laadur annab veateate:

$ mv peamine ..
$ ../main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

Samuti saate utiliidi abil teada saada, milliseid jagatud teeke rakendus vajab ldd:

$ ldd peamine
linux-vdso.so.1 \u003d\u003e (0x00007fffaddff000)
libhello.so.2 \u003d\u003e ./libhello.so.2 (0x00007f9689001000)
libc.so.6 \u003d\u003e /lib/libc.so.6 (0x00007f9688c62000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9689205000)

Väljundis ldd iga nõutava teegi jaoks täpsustatakse selle sonaam ja kogu tee raamatukogu faili juurde, mis määratakse kindlaks vastavalt süsteemi sätetele.

Nüüd on aeg rääkida sellest, kuhu süsteem peaks teegi failid paigutama, kuhu laadija proovib neid leida ja kuidas seda protsessi hallata.

Vastavalt kokkulepetele FHS (failisüsteemi hierarhia standard) süsteemil peab raamatukogufailide hoidmiseks olema kaks (vähemalt) kataloogi:

/ lib - siin kogutakse peamised jaotusraamatukogud, mis on vajalikud programmide jaoks kataloogist / bin ja / sbin tööle;

/ usr / lib - siin hoitakse teeke, mida vajavad rakendusprogrammid kataloogidest / usr / bin ja / usr / sbin;

Teekidele vastavad päisefailid peaksid asuma kataloogis / usr / include.

Laadur otsib vaikimisi nendest kataloogidest teegi faile.

Lisaks ülalloetletutele peab süsteem sisaldama kataloogi / usr / local / lib - seal peavad olema ka teegid, mille kasutaja on iseseisvalt juurutanud, mööda minnes paketihaldussüsteemist (ei kuulu komplekti). Näiteks selles kataloogis on vaikimisi allikatest koostatud teegid (allikatest installitud programmid asuvad kataloogides / usr / local / bin ja / usr / local / sbin, muidugi räägime binaarsetest jaotustest). Sel juhul paigutatakse raamatukogu päised kataloogi / usr / local / include.

Mitmes jaotuses (tuumaühikutes) Ubuntu) laadur ei ole konfigureeritud kataloogi / usr / local / lib sirvimiseks, seega kui kasutaja installib teegi allikatest, ei näe süsteem seda. Seda teevad spetsiaalselt turustuskomplekti autorid, et õpetada kasutajat tarkvara installima ainult paketihaldussüsteemi kaudu. Allpool kirjeldatakse, kuidas sellisel juhul toimida.

Tegelikult ei vaata laadur teegi failide leidmise protsessi lihtsustamiseks ja kiirendamiseks ülaltoodud katalooge iga kord, kui sellele juurde pääseb, vaid tugineb andmebaasis, mis on salvestatud faili /etc/ld.so.cache (teegi vahemälu). See sisaldab teavet selle kohta, kus antud sonamele vastav raamatukogu fail süsteemis asub. Pärast seda, kui laadur on saanud konkreetse rakenduse jaoks vajalike teekide loendi (programmi käivitatavas failis täpsustatud sonaamiteegide loend), kasutab /etc/ld.so.cache iga vajaliku teegi faili juurde jõudmiseks tee tee mällu laadimiseks. Lisaks saab laadur vaadata katalooge, mis on loetletud süsteemimuutujates LD_LIBRARY_PATH, LIBRARY_PATH ja käivitatava faili väljal RPATH (vt ülal).

Teekide vahemälu haldamiseks ja ajakohasena hoidmiseks kasutatakse utiliiti ldconfig... Kui joosta ldconfig ilma võimalike suvanditeta skannib programm käsuribal määratud katalooge, usaldusväärseid katalooge / lib ja / usr / lib, faile /etc/ld.so.conf loetletud katalooge. Iga määratud kataloogides asuva raamatukogufaili jaoks loetakse sonaame, luuakse sonaamil põhinev sümboolne link, värskendatakse /etc/ld.so.cache teavet.

Veendugem järgmises:

$ ls
tere.h libhello.so libhello.so.2.4.0.5 main.c
$
$ sudo ldconfig / full / path / to / kataogu / c / example
$ ls
tere.h libhello.so libhello.so.2 libhello.so.2.4.0.5 main main.c
$ ./main
Esimene funktsioon ...
Teine funktsioon ...
Põhifunktsioon ...

Esimene kõne ldconfig lisasime oma raamatukogu vahemällu, välistasime selle teise kõnega. Pange tähele, et peamise kompileerimisel jäeti see valik tegemata -Wl, -rpath ,.tulemusena otsis laadur vajalikke teeke ainult vahemälust.

Nüüd peaks olema selge, mida teha, kui pärast teegi installimist lähteallikast süsteem seda ei näe. Kõigepealt peate sisestama kogu tee kataloog koos teegi failidega (vaikimisi / usr / local / lib) faili /etc/ld.so.conf. Formaat /etc/ld.so.conf - fail sisaldab kataloogide loendit, eraldatud kooloniga, tühiku, vahekaardi või uue reaga, kust otsida raamatukogusid. Siis helistage ldconfig ilma võimalusteta, kuid superkasutaja õigustega. Kõik peaks toimima.

Noh, lõpuks räägime sellest, kuidas raamatukogude staatilised ja dünaamilised versioonid eksisteerivad koos. Mis on tegelik küsimus? Eespool, kui arutati teegi failide aktsepteeritud nimede ja asukohtade üle, öeldi, et teegi staatiliste ja dünaamiliste versioonide faile hoitakse samas kataloogis. Kuidas gcc saab teada, millist raamatukogu me soovime kasutada? Vaikimisi eelistatakse dünaamilist teeki. Kui linker leiab dünaamilise teegi faili, siis ei kõhkle see linkimast programmi käivitatava failiga:

$ ls
tere.h libhello.a libhello.so libhello.so.2 libhello.so.2.4.0.5 main.c
$ gcc -Wall -c main.c
$ gcc -o peamine main.o -L. -lhello -Wl, -rpath ,.
$ ldd peamine
linux-vdso.so.1 \u003d\u003e (0x00007fffe1bb0000)
libhello.so.2 \u003d\u003e ./libhello.so.2 (0x00007fd50370b000)
libc.so.6 \u003d\u003e /lib/libc.so.6 (0x00007fd50336c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd50390f000)
$ du-h peamine
12K peamine

Pöörake tähelepanu käivitatava programmi suurusele. See on väikseim võimalik. Kõik kasutatavad teegid on dünaamiliselt ühendatud.

Olemas gcc -staatiline variant - linkerile juhendamine kasutama kõigi rakenduse jaoks vajalike teekide ainult staatilisi versioone:

$ gcc -staatiline -o peamine main.o -L. -hello
$ faili peamine
peamine: ELF-i 64-bitine käivitatav LSB, x86-64, versioon 1 (GNU / Linux), staatiliselt lingitud, GNU / Linuxile 2.6.15, eemaldamata
$ ldd peamine
pole dünaamiline käivitatav
$ du-h peamine
Põhiline 728K

Käivitatava faili maht on 60 korda suurem kui eelmises näites - faili on lisatud standardsed keeleteegid C... Nüüd saab meie rakendust turvaliselt kataloogist kataloogi ja isegi teistesse masinatesse üle kanda, teekide raamatukogu kood on faili sees, programm on täiesti autonoomne.

Mis siis, kui peate statistiliselt linkima ainult osa kasutatud teekidest? Võimalik variant lahendused - tehke teegi staatilise versiooni nimi jagatud nimest erinevaks ja rakenduse koostamisel määrake, millist versiooni me seekord kasutada soovime:

$ mv libhello.a libhello_s.a
$ gcc -o peamine main.o -L. -lhello_s
$ ldd peamine
linux-vdso.so.1 \u003d\u003e (0x00007fff021f5000)
libc.so.6 \u003d\u003e /lib/libc.so.6 (0x00007fd0d0803000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd0d0ba4000)
$ du-h peamine
12K peamine

Kuna libhello teegi koodi suurus on tühine,

$ du -h libhello_s.a
4.0K libhello.a

saadud käivitatava faili suurus praktiliselt ei erine dünaamilise linkimise abil loodud faili suurusest.

Noh, see on vist kõik. Suur tänu kõigile, kes sel hetkel lugemise lõpetasid.