gcc-asetukset. gcc-asetukset: Neil Matthew. LSB:n standardikirjastot

Nyt kun tiedät jotain C-standardista, katsotaanpa vaihtoehtoja, joita gcc-kääntäjä tarjoaa varmistaakseen C-standardin noudattamisen kirjoittamallasi kielellä. On kolme tapaa varmistaa, että C-koodisi on standardien mukainen ja siinä ei ole vikoja: vaihtoehdot, jotka hallitsevat standardin versiota, jota aiot noudattaa, määritelmät, jotka hallitsevat otsikkotiedostoja, ja varoitusasetukset, jotka käynnistävät tiukemman tarkistuksen. ohjelmakoodi.

gcc:llä on valtava valikoima vaihtoehtoja, ja tässä tarkastellaan vain niitä, joita pidämme tärkeimpänä. Täydellinen luettelo vaihtoehdoista löytyy gcc online -man sivuilta. Keskustelemme myös lyhyesti joistakin #define direktiivivaihtoehdoista, joita voidaan käyttää; Yleensä ne tulee määrittää lähdekoodissa ennen #include-rivejä tai määritellä gcc-komentorivillä. Saatat yllättyä siitä, kuinka monta vaihtoehtoa on valita käytettävä standardi, sen sijaan että voit valita vain lipun, joka pakottaa sinut käyttämään moderni standardi. Syynä on se, että monet vanhemmat ohjelmat luottavat historialliseen kääntäjien käyttäytymiseen ja vaativat paljon työtä niiden päivittämiseksi uusimpiin standardeihin. Harvoin, jos koskaan, haluat päivittää kääntäjäsi, jotta se katkaisee käynnissä olevan koodin. Standardien muuttuessa on tärkeää pystyä toimimaan tiettyä standardia vastaan, vaikka se ei olisi kaikkein tärkein uusin versio standardi

Vaikka kirjoitat pientä ohjelmaa henkilökohtaiseen käyttöön, jossa standardien noudattaminen ei ehkä ole niin tärkeää, on usein järkevää lisätä gcc-varoituksia, jotta kääntäjä pakotetaan etsimään virheitä koodistasi ennen ohjelman suorittamista. Tämä on aina tehokkaampaa kuin koodin suorittaminen askel askeleelta debuggerissa ja pohtiminen, missä ongelma voi olla. Kääntäjällä on monia vaihtoehtoja, jotka ylittävät yksinkertaisen standardien tarkistamisen, kuten kyky havaita koodia, joka täyttää standardin, mutta jolla voi olla kyseenalainen semantiikka. Esimerkiksi ohjelmalla voi olla suoritusjärjestys, joka sallii muuttujan käytön ennen sen alustusta.

Jos sinun on kirjoitettava ohjelma yhteiskäyttöön, ottaen huomioon vaatimustenmukaisuusasteen ja riittäviksi katsomiensi kääntäjien varoitusten tyypit, on erittäin tärkeää käyttää hieman enemmän vaivaa ja saada koodi kääntämään ilman varoituksia. Jos annat joidenkin varoitusten ilmestyä ja totut jättämään ne huomiotta, jonain päivänä saattaa ilmestyä vakavampi varoitus, jonka saatat jäädä huomaamatta. Jos koodisi käännetään aina ilman varoitusviestejä, uusi varoitus herättää väistämättä huomiosi. Koodin kääntäminen ilman varoituksia on hyvä tapa ottaa käyttöön.

Kääntäjävaihtoehdot standardien seurantaan

Ansi on tärkein standardivaihtoehto ja pakottaa kääntäjän toimimaan ISO C90 -kielistandardin mukaisesti. Se poistaa käytöstä joitakin ei-standardin mukaisia gcc-laajennuksia, poistaa käytöstä C++-tyyliset kommentit (//) C-ohjelmissa ja mahdollistaa ANSI-trigrafien (kolmen merkin sekvenssien) käsittelyn. Lisäksi se sisältää makron __ STRICT_ANSI__, joka poistaa käytöstä jotkin tunnistetiedostojen laajennukset, jotka eivät ole yhteensopivia standardin kanssa. Hyväksytty standardi voi muuttua kääntäjän myöhemmissä versioissa.

Std= - Tämä vaihtoehto mahdollistaa käytetyn standardin tarkemman hallinnan ja tarjoaa parametrin, joka määrittää täsmälleen vaaditun standardin. Alla tärkeimmät mahdollisia vaihtoehtoja:

C89 - tukee C89-standardia;

ISO9899:1999 - tuki uusin versio ISO-standardi, C90;

Gnu89 - tukee C89-standardia, mutta salli joitain GNU-laajennuksia ja joitain toiminnallisuutta C99. Gcc:n versiossa 4.2 tämä vaihtoehto on oletusasetus.

Valinnat vakioseurannalle määritysohjeissa

On vakioita (#defines), jotka voidaan määrittää komentorivillä tai määritelmiksi ohjelman lähdekoodissa. Ajattelemme näitä yleensä kääntäjän komentorivin käyttämisenä.

STRICT_ANSI__ - pakottaa ISO C -standardin käyttöön. Määritetään, kun -ansi-optio on määritetty kääntäjän komentorivillä.

POSIX_C_SOURCE=2 - Ottaa käyttöön IEEE Std 1003.1:ssä ja 1003.2:ssa määritellyt toiminnot. Palaamme näihin standardeihin myöhemmin tässä luvussa.

BSD_SOURCE - Mahdollistaa BSD-järjestelmien toiminnallisuuden. Jos ne ovat ristiriidassa POSIX-määritelmien kanssa, BSD-määritykset ovat etusijalla.

GNU_SOURCE - sallii laaja valikoima ominaisuuksia ja toimintoja, mukaan lukien GNU-laajennukset. Jos nämä määritelmät ovat ristiriidassa POSIX-määritelmien kanssa, jälkimmäiset ovat etusijalla.

Kääntäjän asetukset varoitustulosta varten

Nämä vaihtoehdot välitetään kääntäjälle alkaen komentorivi. Ja jälleen luettelemme vain tärkeimmät, täydellinen lista löytyy interaktiivisesta viiteopas gcc.

Pedantic on tehokkain vaihtoehto C-koodin puhtauden tarkistamiseen.C-standardin tarkistusvaihtoehdon lisäksi se poistaa käytöstä joitakin standardin kieltämiä perinteisiä C-rakenteita ja mitätöi kaikki standardin GNU-laajennukset. Tätä vaihtoehtoa tulisi käyttää C-koodin siirrettävyyden maksimoimiseksi. Haittapuolena on, että kääntäjä on erittäin huolissaan koodisi puhtaudesta, ja joskus sinun on ryhdyttävä aivoihin päästäksesi eroon muutamasta jäljellä olevasta varoituksesta.

Wformat - tarkistaa printf-perhefunktioiden argumenttityyppien oikeellisuuden.

Wsulkeet - tarkistaa sulkeiden olemassaolon, vaikka niitä ei tarvita. Tämä vaihtoehto on erittäin hyödyllinen sen tarkistamiseksi monimutkaiset rakenteet alustettu tarkoitetulla tavalla.

Wswitch-default - tarkistaa oletusasetuksen läsnäolon kytkinkäskyissä, mitä yleensä harkitaan hyvä tyyli ohjelmointi.

Wunused - testaa erilaisia tapauksia, mm. staattiset toiminnot ilmoitettu, mutta ei kuvattu, käyttämättömät parametrit, hylätyt tulokset.

Seinä - Mahdollistaa useimmat gcc-varoitustyypit, mukaan lukien kaikki aiemmat -W-vaihtoehdot (vain -pedantic ei ole katettu). Sen avulla on helppo saavuttaa puhdas koodi.

Huomautus

Saatavilla on monia kehittyneempiä varoitusvaihtoehtoja, katso lisätietoja gcc:n web-sivuilta. Yleensä suosittelemme -Wall; tämä on hyvä kompromissi ohjelmakoodin varmistamisen välillä Korkealaatuinen, ja kääntäjän tarve tuottaa massa triviaaleja varoituksia, joita on vaikea vähentää nollaan.

GCC on vapaasti saatavilla optimointikääntäjä C-, C++-kielille.

Ohjelmoida gcc, käynnistetään komentoriviltä, on lisäosa kääntäjien ryhmään. Parametreina ja lisäasetuksina välitetyistä tiedostopäätteistä riippuen, gcc käynnistää tarvittavat esiprosessorit, kääntäjät, linkkerit.

Tiedostot, joissa on laajennus .cc tai .C katsotaan tiedostoiksi C++-kielellä, tiedostoina, joiden tunniste on .c ohjelmina C-kielellä ja tiedostoilla, joiden tunniste on .o pidetään objektiivisina.

Kääntääksesi tiedostosta löytyvän C++-lähdekoodin F.cc ja luo objektitiedosto F.o, sinun on suoritettava komento:

Gcc -c F.cc

Vaihtoehto -c tarkoittaa "vain käännös".

Yhden tai useamman lähdekoodista johdetun objektitiedoston linkittäminen - F1.o, F2.o, ... - yhdeksi suoritettavaksi tiedostoksi F, sinun on annettava komento:

Gcc -o F F1.o F2.o

Valinta -o määrittää suoritettavan tiedoston nimen.

Voit yhdistää kaksi käsittelyvaihetta - kokoamisen ja linkityksen - yhdeksi yleisvaiheeksi komennolla:

Gcc -o F F1.cc ... -lg++

- mahdolliset lisäkokoamis- ja linkitysvaihtoehdot. Valinta –lg++ ilmaisee tarpeen sisällyttää C++-kielen vakiokirjasto, - mahdolliset lisäkirjastot.
Kun linkki on tehty, luodaan suoritettava tiedosto F, joka voidaan ajaa komennolla

./F

- luettelo ohjelman komentoriviargumenteista.
Kirjastoja käytetään usein linkitysprosessin aikana. Kirjasto on kokoelma objektitiedostoja, jotka on ryhmitelty yhdeksi tiedostoksi ja indeksoitu. Kun linkkikomento kohtaa kirjaston linkitettävien objektitiedostojen luettelossa, se tarkistaa, sisältävätkö linkitetyt objektitiedostot jo kutsuja jossakin kirjastotiedostossa määritettyihin funktioihin. Jos tällaisia toimintoja löytyy, vastaavat kutsut liitetään kirjaston objektitiedostokoodiin. Kirjastot voidaan sisällyttää -lname-valitsimen avulla. Tässä tapauksessa vakiohakemistoissa, kuten /lib , /usr/lib, /usr/local/lib kirjastoa etsitään tiedostosta nimeltä libname.a. Kirjastot tulee listata lähde- tai objektitiedostojen jälkeen, jotka sisältävät kutsuja vastaaviin toimintoihin.

Kokoonpanovaihtoehdot

Monista kokoamis- ja linkitysvaihtoehdoista yleisimmin käytetyt ovat:

Vaihtoehto	Tarkoitus
-c	Tämä vaihtoehto tarkoittaa, että vain kokoaminen on välttämätöntä. Ohjelman lähdetiedostoista luodaan lomakkeeseen objektitiedostot nimi.o. Asettelua ei suoriteta.
-Dname=arvo	Määritä nimi käännetyssä ohjelmassa v:n arvoksi alue. Vaikutus on sama kuin linjalla #määritä nimen arvo ohjelman alussa. Osa = arvo voidaan jättää pois, jolloin oletusarvo on 1.
-o tiedostonimi	Käyttää Tiedoston nimi luodun tiedoston nimeksi.
-nimi	Käytä libname.so-kirjastoa linkittäessäsi
-Llib-polku -Sisällytä-polku	Lisää lib-path ja include-path kirjastojen ja otsikkotiedostojen vakiohakuhakemistoihin.
-g	Sijoita virheenkorjausohjelman virheenkorjaustiedot objektiin tai suoritettavaan tiedostoon gdb. Vaihtoehto on määritettävä sekä käännökselle että linkittämiselle. Yhdistelmänä -g On suositeltavaa käyttää vaihtoehtoa optimoinnin poistamiseksi käytöstä -O0(Katso alempaa)
-MM	Tulosriippuvuudet C- tai C++-ohjelmassa käytetyistä otsikkotiedostoista apuohjelmalle sopivassa muodossa tehdä. Objekteja tai suoritettavia tiedostoja ei luoda.
-s	Aseta profilointiohjeet objektiin tai suoritettavaan tiedostoon apuohjelman käyttämien tietojen luomiseksi gprof. Vaihtoehto on määritettävä sekä käännökselle että linkittämiselle. Koottuna vaihtoehdolla -s Ohjelma luo tilastotiedoston käynnistettäessä. Ohjelmoida gprof luo tämän tiedoston perusteella transkription, joka osoittaa kunkin toiminnon suorittamiseen käytetyn ajan.
- Seinä	Näyttää viestejä varoituksista tai virheistä, joita esiintyy ohjelman kääntämisen aikana.
-O1 -O2 -O3	Eri tasoisia optimointia.
-O0	Älä optimoi. Jos käytät useita -O vaihtoehtoja tasonumeroilla tai ilman, viimeinen vaihtoehto on voimassa.
-Minä	Käytetään omien hakemistojesi lisäämiseen otsikkotiedostojen etsimiseen rakennusprosessin aikana
-L	Siirretty linkkerille. Käytetään omien kirjastohakuhakemistojesi lisäämiseen rakennusprosessin aikana.
-l	Siirretty linkkerille. Käytetään omien kirjastojen lisäämiseen haettavaksi rakennusprosessin aikana.

Linux-käyttöjärjestelmä ilmestyi ensin vain järjestelmäytimenä. Valitettavasti ydin itsessään ei ole kovin hyödyllinen; ohjelmat vaativat rekisteröinnin, tiedostojen hallinnan, uusien ohjelmien kokoamisen jne. Jotta järjestelmästä olisi hyötyä, GNU-projekti on lisännyt useita ominaisuuksia. Ne olivat samanlaisten ohjelmien klooneja, jotka olivat saatavilla tuolloin UNIX- ja UNIX-tyyppisissä järjestelmissä. Linuxin muuttaminen UNIXin kaltaiseksi järjestelmäksi asetti ensimmäiset standardit Linuxille tarjoten C-ohjelmoijille tutun työympäristön.

Eri UNIX- (ja myöhemmin Linux) -kehittäjät lisäsivät omia laajennuksiaan järjestelmän mukana toimittamiinsa komentoihin ja apuohjelmiin, ja myös käyttämiensa tiedostojärjestelmien rakenne poikkesi hieman. Kaikki tämä vaikeutti eri järjestelmissä toimivien sovellusten luomista. Ohjelmoija ei myöskään voinut luottaa siihen, että järjestelmän toiminnallisuus toteutetaan samalla tavalla tai konfigurointitiedostot on tallennettu samaan paikkaan.

Tuli selväksi, että standardointia tarvitaan UNIX-järjestelmien samankaltaisuuden säilyttämiseksi, ja tällainen työ on nyt käynnissä.

Ajan myötä standardit eivät ole vain edistyneet, vaan yhteisö on parantanut Linux-käyttöjärjestelmää vaikuttavalla nopeudella kaupallisten organisaatioiden, kuten Red Hatin ja Canonicalin, ja jopa muiden kuin Linux-kehittäjien, kuten IBM:n, tukemana. Linuxin kehittyessä ja kääntäjien kokoelman kehityksen myötä gcc ei vain ylläpitänyt asiaankuuluvia standardeja, vaan myös määritellyt uusia standardeja, jos olemassa olevat havaittiin tehottomiksi. Itse asiassa, kun Linux-käyttöjärjestelmä ja siihen liittyvät ohjelmistot ja apuohjelmat yleistyivät, UNIX-järjestelmän kehittäjät alkoivat tehdä muutoksia tuotteisiinsa tehdäkseen niistä yhteensopivia Linux-käyttöjärjestelmän kanssa.

Tässä viimeisessä luvussa tarkastelemme Linux-standardeja keskittyen alueisiin, jotka sinun on tiedettävä, jotta voit paitsi kirjoittaa sovelluksia, jotka toimivat Linux-järjestelmissäsi niiden päivityksen jälkeen, myös luodaksesi koodia, joka voi olla kannettava. Linux-jakeluihin ja ehkä UNIX-tyyppisiin järjestelmiin, mikä varmistaa ohjelmiesi jakamisen.

Käsittelemme erityisesti seuraavia aiheita:

□ C-ohjelmointikielen standardi;

□ UNIX-standardit, erityisesti POSIX, jonka on kehittänyt IEEE, ja Single UNIX Specification, jonka on kehittänyt Open Group;

□ Free Standards Groupin kehittämä kehitys, erityisesti Linux Standard Base, joka määrittelee tavallisen Linux-tiedostojärjestelmän asettelun.

Hyvä lähtökohta Linux-käyttöjärjestelmäkohtaisten standardien ymmärtämiselle on Linux Standard Base (LSB), joka löytyy Linux Foundationin web-sivustolta osoitteesta http://www.linux-foundation.org/.

Emme aio mennä yksityiskohtiin standardien sisällöstä, sillä monet niistä ovat laajuudeltaan verrattavissa tähän kirjaan. Haluamme korostaa tärkeimpiä standardeja, joista sinun tulee olla tietoinen, antaa sinulle lyhyen historian näiden standardien kehityksestä ja auttaa sinua päättämään, mitkä niistä voivat olla hyödyllisiä omien ohjelmien kirjoittamisessa.

C-ohjelmointikieli

C-ohjelmointikieli on de facto Linux-käyttöjärjestelmän ohjelmointikieli, joten C-ohjelmien kirjoittamiseksi Linuxille sinun on ymmärrettävä hieman sen alkuperää, selvitettävä, kuinka kieli on muuttunut, ja mikä tärkeintä, ymmärrettävä miten ohjelmien standardien mukaisuus tarkistetaan.

Lyhyt historian oppitunti

Niille, jotka eivät ole kovinkaan historian ystävä, älä huoli: tämä kirja käsittelee ohjelmointia, ei historiaa, joten katsaus on hyvin lyhyt.

C-ohjelmointikieli syntyi 1970-luvun alussa ja perustui osittain aikaisempaan BCPL-ohjelmointikieleen ja B-kielen laajennuksiin. Dennis M. Ritchie kirjoitti kielelle käyttöoppaan vuonna 1974, ja suunnilleen samaan aikaan C:tä käytettiin mm. ohjelmointikieli UNIX-ytimen muokkaamiseen PDP-11-tietokoneissa. Vuonna 1978 Brian W. Kernighan ja Ritchie kirjoittivat klassisen käsikirjan kielestä, The C Programming Language.

Hyvin nopeasti kieli saavutti suuren suosion, mikä johtuu epäilemättä osittain UNlX-järjestelmien suosion nopeasta kasvusta, mutta myös sen ominaisuuksista ja ymmärrettävästä syntaksista. C-kielen syntaksi kehittyi edelleen johdonmukaisesti, mutta kun se muuttui yhä enemmän kirjassa annetusta alkuperäisestä kuvauksesta, kävi selväksi, että tarvitaan nykyaikaisen käytön mukainen standardi, joka oli tiukempi.

Vuonna 1983 ANSI (American National Standards Institute) perusti X3J11-standardikomitean kehittämään selkeän ja tiukan määritelmän kielelle. Matkan varrella molemmat organisaatiot tekivät pieniä muutoksia kieleen, mikä erityisesti antoi sille kauan odotetun mahdollisuuden ilmoittaa parametrityypit, mutta enimmäkseen komitea yksinkertaisesti toi selkeyttä ja perusteluja olemassa olevaan määritelmään siitä, mikä muodostaa kielen yhteisen kieliversion. . Lopullinen standardi julkaistiin vuonna 1989 nimellä ANSI Standard Programming Language C, X3.159-1989 tai lyhyemmin C89, jota joskus kutsutaan nimellä C90. (Tämä jälkimmäinen muuttui ISO/IEC 9899:1990 -standardiksi Ohjelmointikielet - C. Molemmat standardit ovat muodollisesti identtisiä.)

Kuten useimpien standardien kohdalla, julkaisu ei päättänyt komitean työtä, vaan se jatkoi joidenkin spesifikaatiossa havaittujen epätarkkuuksien poistamista ja aloitti standardin uuden version, nimeltään C9X, työskentelyn vuonna 1993. Valiokunta julkaisi myös pieniä muutoksia ja päivityksiä olemassa oleva standardi vuosina 1994-1996

Uusi versio standardi tehtiin 1990-luvulla. ja siitä tuli virallisesti C99-standardi; ISO on hyväksynyt sen standardiksi ISO/IEC 9899:1999. C-kielen ja sen kirjastojen standardointia valvova J11-komitea toimii edelleen, mutta se toimii nyt Kansainvälisen tietotekniikan standardikomitean ryhmän alaisuudessa. tietotekniikat). Lisätietoja C-standardointityöstä on verkkosivustolla http://j11.incits.org/.

GNU Compiler Collection

Emacs-editorin kehittämisen jälkeen (kyllä, me rakastamme Emacsia), GNU-projektin seuraava suuri saavutus, kuten mainittiin luku 1, tuli täysin ilmainen C-kääntäjä, gcc, ensimmäinen virallinen versio joka julkaistiin vuonna 1987.

Nimi gcc merkitsi alun perin sanoista GNU C Compiler (GNU Projectin C-kääntäjä), mutta koska taustalla oleva kääntäjän ajonaika tukee nyt monia muita ohjelmointikieliä, kuten C++, Objective-C, FORTRAN, Java ja Ada, sekä näiden kirjastoja. kielet, määritelmä on korvattu sopivammalla GNU Compiler Collection -kokoelmalla (GNU-kääntäjien kokoelma).

gcc on aina ollut ja näyttää pysyvän vakiokääntäjänä Linuxille ja C tai C++, pääkieli ohjelmien kirjoittamiseen Linux-käyttöjärjestelmässä. Kotisivu gcc löytyy osoitteesta http://gcc.gnu.org/.

GNU C-kääntäjä on aina pitänyt hyvää kirjaa C-kielistandardin kehityksestä, vaikka se salliikin joitain kielen laajennuksia, ja tietysti standardin julkaisun ja kääntäjien välillä on pieniä viiveitä, kuten lähes kaikilla kääntäjillä. Sellaisten kääntäjien versioiden julkaisu, jotka noudattavat tarkasti määritelmiä. Joskus tapahtuu päinvastoin, ja gcc ennakoi heikkoja muutoksia standardiin, mikä voi myös olla täysin hämmentävää. gcc:ssä on useita komentorivi- ja muita valintoja, joiden avulla voit määrittää C-kielistandardin version, jota kääntäjän on noudatettava, sekä useita muita vaihtoehtoja, joilla ohjataan kääntäjän nirsoa tai tiukkaa.

gcc-asetukset

Nyt kun tiedät jotain C-standardista, katsotaanpa vaihtoehtoja, joita gcc-kääntäjä tarjoaa varmistaakseen C-standardin noudattamisen kirjoittamallasi kielellä. On kolme tapaa varmistaa, että C-koodisi on standardien mukainen ja siinä ei ole puutteita: vaihtoehdot, jotka hallitsevat standardin versiota, jota aiot noudattaa, määritelmät, jotka hallitsevat otsikkotiedostoja, ja varoitusvaihtoehdot, jotka käynnistävät tiukemman koodin tarkistuksen.

, jota voidaan soveltaa; Tyypillisesti ne tulee määrittää lähdekoodissa ennen komentoriviä tai määritellä gcc-komentorivillä. Saatat yllättyä siitä, kuinka monta vaihtoehtoa on valita käytettävä standardi sen sijaan, että vain tarkistaisit lipun pakottaaksesi nykyisen standardin käyttöön. Syynä on se, että monet vanhemmat ohjelmat luottavat historialliseen kääntäjien käyttäytymiseen ja vaativat paljon työtä niiden päivittämiseksi uusimpiin standardeihin. Harvoin, jos koskaan, haluat päivittää kääntäjäsi, jotta se katkaisee käynnissä olevan koodin. Standardien muuttuessa on tärkeää pystyä toimimaan tiettyä standardia vastaan, vaikka se ei olisikaan standardin uusin versio.

Kääntäjävaihtoehdot standardien seurantaan- Tämä on tärkein standardivaihtoehto ja pakottaa kääntäjän toimimaan ISO C90 -kielistandardin mukaisesti. Se poistaa käytöstä jotkin gcc-laajennukset, jotka eivät ole standardiyhteensopivia, poistaa C++-tyyliset kommentit () käytöstä C-ohjelmissa ja mahdollistaa ANSI-trigrafien (kolmen merkin sekvenssien) käsittelyn. Lisäksi se sisältää __-makron, joka poistaa käytöstä joitakin laajennuksia otsikkotiedostoista, jotka eivät ole yhteensopivia standardin kanssa. Hyväksytty standardi voi muuttua kääntäjän myöhemmissä versioissa. - Tämä vaihtoehto mahdollistaa käytetyn standardin tarkemman hallinnan tarjoamalla parametrin, joka määrittää täsmälleen vaaditun standardin. Seuraavat ovat tärkeimmät mahdolliset vaihtoehdot: - C89-standardin tuki; - tukee ISO-standardin C90 uusinta versiota; - tukevat C89-standardia, mutta sallivat joitain GNU-laajennuksia ja joitakin C99-toimintoja. Gcc:n versiossa 4.2 tämä vaihtoehto on oletusasetus. Valinnat standardin seurantaan direktiiveissä määritellä

On vakioita (

), jotka voidaan määrittää komentorivin vaihtoehdoilla tai määritelminä ohjelman lähdekoodissa. Ajattelemme näitä yleensä kääntäjän komentorivin käyttämisenä. - pakottaa käyttämään ISO-standardia C. Määritetään, kun vaihtoehto on määritetty kääntäjän komentorivillä. - Ottaa käyttöön IEEE Std 1003.1:n ja 1003.2:n määrittämät toiminnot. Palaamme näihin standardeihin myöhemmin tässä luvussa. - sisältää BSD-järjestelmien toimintoja. Jos ne ovat ristiriidassa POSIX-määritelmien kanssa, BSD-määritykset ovat etusijalla. - Mahdollistaa laajan valikoiman ominaisuuksia ja toimintoja, mukaan lukien GNU-laajennukset. Jos nämä määritelmät ovat ristiriidassa POSIX-määritelmien kanssa, jälkimmäiset ovat etusijalla. Kääntäjän asetukset varoitustulosta varten

Nämä valinnat välitetään kääntäjälle komentoriviltä. Luettelemme jälleen vain tärkeimmät; täydellinen luettelo löytyy gcc:n online-käyttöoppaasta.

- Tämä on tehokkain vaihtoehto C-koodin puhtauden tarkistamiseen. C-standardin noudattamisen tarkistusvaihtoehdon käyttöönoton lisäksi se poistaa käytöstä jotkin perinteiset C-rakenteet, jotka standardi kieltää, ja tekee kaikista GNU-laajennuksista virheellisiä suhteessa standardiin . Tätä vaihtoehtoa tulisi käyttää C-koodin siirrettävyyden maksimoimiseksi. Haittapuolena on, että kääntäjä on erittäin huolissaan koodisi puhtaudesta, ja joskus sinun on ryhdyttävä aivoihin päästäksesi eroon muutamasta jäljellä olevasta varoituksesta. - tarkistaa perhefunktioiden argumenttityyppien oikeellisuuden. - tarkistaa sulkeiden olemassaolon, vaikka niitä ei tarvitakaan. Tämä vaihtoehto on erittäin hyödyllinen sen varmistamiseksi, että monimutkaiset rakenteet alustetaan tarkoitetulla tavalla. - tarkistaa muunnelman esiintymisen lauseissa, jota pidetään yleisesti hyvänä ohjelmointityylinä. - tarkistaa erilaisia tapauksia, esimerkiksi staattiset funktiot, jotka on ilmoitettu mutta joita ei ole kuvattu, käyttämättömät parametrit, hylätyt tulokset. - sisältää useimmat gcc-varoitustyypit, mukaan lukien kaikki aiemmat vaihtoehdot - (vain ei kata). Sen avulla on helppo saavuttaa puhdas koodi.

Huomautus
Saatavilla on monia kehittyneempiä varoitusvaihtoehtoja, katso lisätietoja gcc:n web-sivuilta. Yleisesti suosittelemme käyttämään
; Tämä on hyvä kompromissi tarkistuksen, joka varmistaa korkealaatuisen koodin, ja kääntäjän tarpeen antaa joukko triviaaleja varoituksia, joita on vaikea vähentää nollaan.

Liitännät ja Linux-standardipohja

Nyt siirrymme tasoa ylöspäin ja siirrymme C-ohjelmoinnista käyttöjärjestelmän tarjoamien liitäntöjen (järjestelmätoimintojen) tarkasteluun. Tällä standardointitasolla on erilaisia komponentteja: kirjastojen tarjoamat toiminnot ja käyttöjärjestelmän matalalla tasolla toteuttamat järjestelmäkutsut. Molemmilla on kaksi yksityiskohtatasoa: mitkä rajapinnat ovat edustettuina ja määritelmä siitä, mitä kukin käyttöliittymä tekee.

Tämän alueen määrittävä asiakirja Linux-käyttöjärjestelmälle on Linux Standards Base (LSB, käyttöjärjestelmästandardit Linux-pohjainen), jotka löytyvät verkkosivuilta http://mvw.linuxbase.org tai http://www.linux-foundation.org/en/LSB. Standardeista on jo julkaistu useita versioita, ja työ jatkuu.

Luettelo sertifioiduista jakeluista löytyy osoitteesta http://www.linux-foundation.org/en/Products. Useat Red Hatin, SUSE:n ja Ubuntun versiot ovat sertifioituja, mutta muista, että jakelun julkaisun jälkeen saattaa kulua jonkin aikaa ennen kuin sertifiointi tapahtuu. Web-sivustolla on luettelo jakeluista, joita testataan tai jotka tarvitsevat vain joitain päivityksiä sertifiointitestien läpäisemiseksi.

Linux Standards Base (versiosta 3.1 alkaen) määrittelee kolme aluetta vaatimustenmukaisuuden testaukselle:

□ ydin - pääkirjastot, apuohjelmat ja tärkeimpien tiedostojärjestelmän komponenttien sijainti;

□ C++ - C++-kirjastot;

□ työpöytä - lisätiedostoja työpöydän asetuksiin, pääasiassa erilaisia graafisia kirjastoja.

Erittelyssä olemme eniten kiinnostuneita ytimestä.

LSB-standardi kattaa useita alueita omassa dokumentaatiossaan, mutta viittaa myös ulkoisiin standardeihin tiettyjen rajapintojen määrittelyissä. Standardi kattaa seuraavat alueet:

□ objektitiedostomuodot binaariyhteensopivuutta varten;

□ dynaamiset linkitysstandardit;

□ standardikirjastot, sekä ydin- että X Window System -kirjastot;

□ komentotulkki ja muut komentoriviohjelmat;

□ ajonaikainen ympäristö, mukaan lukien käyttäjät ja ryhmät;

□ järjestelmän alustus ja ajotasot.

Tässä luvussa käsitellään vain vakiokirjastoja, käyttäjiä ja järjestelmän alustusta.

LSB:n standardikirjastot

Linux Standard Base -dokumentaatio määrittelee kahdella tavalla liitännät, jotka on oltava läsnä. Joillekin toiminnoille, jotka on toteutettu enimmäkseen GNU Project C -kirjastolla tai jotka ovat yleensä vain Linux-standardeja, sekä käyttöliittymä että sen toiminta on määritelty. Muissa liitännöissä, erityisesti niille, joissa on UNIX-tyyppinen kehys, standardi sanoo yksinkertaisesti, että liitännän on oltava olemassa ja sen on toimittava toisen standardin, tyypillisesti Common Application Environment (CAE) tai yleisemmin Single UNIX Specification UNIXin määrittelemällä tavalla. spesifikaatio), joka on saatavilla Open Groupin verkkosivuilla http://www.opengroup.org. Jotkut osat löytyvät (ilmoittautuminen vaaditaan tällä hetkellä) osoitteessa http://www.unix.org/online.html.

Valitettavasti taustalla olevilla Linux- ja UNIX-standardeilla on melko monimutkainen menneisyys, ja valinnanvaraa on liikaa, vaikka yleensä eri versiot ovat melkein yhteensopivia.

Lyhyt historian oppitunti

UNIX OS syntyi 1960-luvun lopulla. AT&T:n Bell Laboratories -divisioona, kun Ken Thompson ja Dennis Ritchie kirjoittivat alun perin vain henkilökohtaiseen käyttöön tarkoitetun käyttöjärjestelmän, jota he kutsuivat Unicsiksi. Jotenkin nimi muuttui UNIXiksi. AT&T antoi yliopistoille mahdollisuuden käyttää lähdekoodia omaan kehitykseensä, ja UNIXista tuli nopeasti uskomattoman suosittu erittäin selkeän loogisen rakenteensa ja tehokkaiden ideoidensa ansiosta. Lähdekoodin saatavuuden olisi pitänyt olla merkittävä kannustin, koska se antoi ohjelmoijille mahdollisuuden tehdä muutoksia ja kokeilla.

BSD-käyttöjärjestelmä oli vaihtoehto, joka syntyi Kalifornian yliopistossa Berkeleyssä, jossa painotettiin paljon verkon organisointia ja ylläpitoa.

Kun AT&T alkoi tehdä UNIXista kaupallista järjestelmää, mikä tapahtui enimmäkseen 1980-luvun puolivälissä, se kutsui julkaisuja UNIX-järjestelmät System, ja suosituin oli UNIX System V.

Monia muita muunnelmia syntyi, liian monia tässä luettelemiseksi, joissa kaikissa oli pieniä eroja perusstandardeista ja joitain lisäyksiä, kun yritykset yrittivät lisätä tuotteeseen lisäarvoa luomalla omia laajennuksiaan.

Asiat muuttuivat todella monimutkaisiksi, kun AT&T myi UNIX-liiketoiminnan Novellille, joka päätti lopettaa sen vuonna 1994, ja oikeuksien ja tavaramerkkien omistajuudesta tuli epävarma asia, johon kohdistui useita oikeusjuttuja.

Vuonna 1988 IEEE (Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers, http://www.ieee.org) julkaisi ensimmäiset standardit: POSIX tai IEEE 1003 - standardit, jotka oli tarkoitettu tietokoneiden käyttöjärjestelmien kannettavan käyttöliittymän määrittelyksi. Vaikka se on hyvä ja hyvin määritelty standardi, POSIX on myös hyvin pitkälti ytimen spesifikaatio, jonka soveltamisala on hyvin rajallinen.

Vuonna 1994 X/Open Company, ei-toimittajaorganisaatio, julkaisi kattavamman määrityssarjan, X/Open CAE- eli Common Applications Environment -ympäristön, joka on IEEE POSIX -standardien laajennus ja on muodollisesti identtinen niiden kanssa monissa maissa. alueilla. X/Open yhdistettiin myöhemmin OSF:ään (Free Software Foundation). ohjelmisto) avoimen ryhmän perustamiseksi; sen kotisivu sijaitsee osoitteessa http://www.opengroup.org/. CAE-standardi tarkistettiin ja julkaistiin vuonna 2002 Single UNIX Specification, Version 3, jonka on kehittänyt Open Group.

Juuri tähän spesifikaatioon viitataan useimmiten Linux-standardipohjassa.

Huomautus
On huomattava, että "Linux" on tavaramerkki, jonka omistaa Linus Torvalds. cm. http://www.linuxmark.org/.

LSB-standardin soveltaminen kirjastoihin

Tarpeeksi standardien luomisen historiasta. Mitä se tarkoittaa ihmisille ohjelmien kirjoittaminen C:ssä (tai C++:ssa) niiden siirrettävyyden vaatimus?

Ensin sinun on varmistettava, että käyttämäsi kirjastotoiminto on LSB-standardin mukainen. Jos se ei ole siellä, saatat tehdä jotain, joka ei helposti siirry toiseen järjestelmään, ja sinun kannattaa katsoa standardi tapa ongelman toteuttaminen, jota yrität ratkaista. Ehkä kannattaa kokeilla Linux-komento apropos, joka etsii online-ohjesivuilta asiaankuuluvia linkkejä.

Toiseksi, ja vielä vaikeampaa, sinun tulee varmistaa, että käyttämäsi funktion käyttäytyminen sisältyy standardiin ja että et luota käyttäytymiseen, jota ei ole kuvattu standardissa. Saatat joutua tutustumaan Single UNIX -määritykseen, jos funktion käyttöä ei ole määritelty LSB-standardissa. Erittäin hyvä tapa Tarkista määrittelemätön tai mahdollisesti virheellinen toiminta - katso Linuxin online-käsikirja. Monilla sen sivuilla on "BUGS"-osio, joka on korvaamaton tietolähde siitä, missä Linuxissa tietty kutsu ei täysin toteuta standardeja tai missä käyttäytymisessä on puutteita ja omituisuuksia.

LSB:n käyttäjät ja ryhmät

Tämä standardin osa on tarkka, ytimekäs ja selkeä. Seuraavassa on joitain standardin vaatimuksia.

□ Määrittely edellyttää, että saadaksesi yksityiskohtaiset käyttäjätiedot, älä koskaan lue tiedostoja, kuten /etc/passwd, suoraan, vaan käytä aina tavallisia kirjastokutsuja, esim.

, tai esimerkiksi tavalliset apuohjelmat.

□ Standardi edellyttää juuriryhmässä root-nimistä käyttäjää, joka on järjestelmänvalvoja, jolla on täydet oikeudet tai käyttöoikeudet. Löydämme standardista myös joukon valinnaisia käyttäjä- ja ryhmänimiä, joita ei koskaan tulisi käyttää vakiosovelluksissa; ne on tarkoitettu jakelujen käyttöön.

□ Standardissa todetaan myös, että alle 100 tunnukset ovat järjestelmätunnuksia Tilit, alue 100-499 on järjestelmänvalvojien ja asennuksen jälkeisten komentosarjojen käytössä, ja lopuksi tunnusnumerot 500 ja sitä suuremmat on tarkoitettu tavallisille käyttäjätileille.

Yleisesti ottaen useimpien Linux-ohjelmoijien tulisi olla tietoisia käyttäjiin liittyvistä standardivaatimuksista.

LSB-järjestelmän alustus

Järjestelmän alustuksen tai käynnistyksen alue on aina, ainakin meille, ollut huolenaihe hienovaraisten jakeluerojen vuoksi.

Linux-järjestelmä peri UNIX-tyyppisiltä käyttöjärjestelmiltä ajatuksen ajotasoista tai ajotasoista, jotka määrittelevät järjestelmässä jatkuvasti käynnissä olevat palvelut. Taulukossa 18.1 tarjoaa vakiomääritykset Linux-käyttöjärjestelmälle.

Taulukko 18.1

Juoksu tasolla	Kuvaus
0	Pysäyttää. Käytetään loogisena tilana, johon siirrytään, kun järjestelmä pysähtyy
1	Yhden käyttäjän tila. Muita hakemistoja kuin / (juuri) ei saa liittää, eikä niillä ole verkkotukea. Yleensä käytetään järjestelmän ylläpitoon
2	Moninpelitila, mutta ei online-tukea
3	Tavallinen moninpeli online-tuella tekstitilan kirjautumisnäytöllä
4	Varattu
5	Tavallinen online-moninpeli graafisella kirjautumisnäytöllä
6	Pseudo-taso, jota käytetään uudelleenkäynnistykseen

LSB-standardi tarjoaa nämä tasot, mutta ei vaadi niiden käyttöä, vaikka ne ovat hyvin yleisiä.

Mukana olevat ajotasot ovat joukko init-skriptejä, joita käytetään palveluiden käynnistämiseen, pysäyttämiseen ja uudelleenkäynnistykseen. Aikaisemmin ne tallennettiin eri paikkoihin /etc-hakemistossa, usein hakemistoon /etc/init.d tai /etc/rc.d/init.d. Tämä vaihtelu aiheutti usein hämmennystä, koska jakelua vaihtaneet käyttäjät eivät löytäneet init-skriptejä tavallisista paikoista ja ohjelmien asennus epäonnistui, jos he yrittäisivät suorittaa init-skriptin väärästä hakemistosta.

LSB 3.1 -standardi määrittelee /etc/init.d-hakemiston init-skriptien tallennuspaikaksi, mutta se sallii myös tämän hakemiston olla linkki järjestelmän toiseen sijaintiin.

Jokaisella /etc/init.d-hakemiston komentosarjalla on nimi, joka liittyy sen tarjoamaan palveluun. Koska kaikkien Linux-käyttöjärjestelmän palveluiden on jaettava sama nimiavaruus, on tärkeää, että nämä nimet ovat yksilöllisiä. Esimerkiksi elämästä tulee vaikeaa, jos MySQL- ja PostgreSQL-palvelut päättävät nimetä komentosarjoilleen "tietokanta". Tämän ristiriidan ratkaisemiseksi on olemassa toinen joukko standardeja. Tämä on Assigned Names And Numbers Authority (LANANA) -standardi, joka löytyy verkkosivustolta http://www.lanana.org/. Onneksi sinun on tiedettävä tästä standardista hyvin vähän, paitsi että se tallentaa luettelon rekisteröidyistä komentosarjan ja pakettien nimistä, mikä helpottaa käyttäjien elämää Linux-järjestelmät.

Init-skriptin on hyväksyttävä parametri, joka ohjaa sen toimintaa. Standardi määrittelee taulukossa luetellut parametrit. 18.2.

Taulukko 18.2

Parametri	Merkitys
	Käynnistää (tai käynnistää uudelleen) palvelun
	Pysäyttää palvelun
	Käynnistää palvelun uudelleen; yleensä toteutetaan yksinkertaisena palvelun pysäyttämisenä, jota seuraa kyseisen palvelun käynnistäminen
	Asentaa palvelun uudelleen lataamalla parametrit uudelleen pysäyttämättä palvelua. Kaikki palvelut eivät tue tätä vaihtoehtoa, joten tämä vaihtoehto ei ehkä ole käytettävissä joissakin skenaarioissa, tai jos se on saatavilla, sillä ei ehkä ole vaikutusta
	Yrittää pakottaa uudelleenasennuksen, jos palvelu tukee sitä; jos ei, se käynnistää palvelun uudelleen
	Tulostaa tekstiviestin palvelun tilasta ja palauttaa tilakoodin, jonka avulla voidaan määrittää palvelun tila

Kaikki komennot palauttavat 0:n, jos onnistuvat, tai virhekoodin, joka ilmaisee epäonnistumisen syyn. Parametrin tapauksessa

palauttaa 0:n, jos palvelu on käynnissä; kaikki muut koodit tarkoittavat, että palvelu ei jostain syystä ole käynnissä.

Tiedostojärjestelmän laitestandardi

Viimeinen standardi, jota tarkastelemme tässä luvussa, on tiedostojärjestelmähierarkiastandardi (FHS). Se löytyy osoitteesta http://www.polunnimi.com/fhs/.

Tämän standardin tarkoituksena on määrittää tyypilliset tallennuspaikat Linux-tiedostojärjestelmässä, jotta sekä kehittäjät että käyttäjät voivat tehdä valistuneita arvauksia tiettyjen tiedostojen sijainnista. UNIX-tyyppisten käyttöjärjestelmien pitkäaikaiset käyttäjät ovat jo pitkään valittaneet hienovaraisista eroista tiedostojärjestelmän asetteluissa, ja FHS-standardi tarjoaa Linux-jakeluille tavan välttää tätä epätasaista polkua.

Linux-järjestelmän tiedostoasettelu saattaa ensi silmäyksellä tuntua puolimielisesti tiedostojen ja hakemistojen rakenteelta, joka perustuu historiallisiin ideoihin. Tämä on osittain totta, mutta vuosien varrella asettelu on oikeutetusti kehittynyt nykyiseen hierarkiaan. Sen pääideana on jakaa tiedostot ja hakemistot kolmeen ryhmään:

□ tietylle käynnissä olevalle Linux-järjestelmälle ainutlaatuiset tiedostot ja hakemistot, kuten käynnistyskomentosarjat ja asetustiedostot;

□ tiedostot ja hakemistot, jotka ovat vain luku -tilassa ja joita mahdollisesti jakavat useat käynnissä olevat Linux-järjestelmät, esim. suoritettavat tiedostot sovellukset;

□ hakemistot, joita luetaan/kirjoitetaan, mutta jotka mahdollisesti jaetaan Linuxin tai muiden järjestelmien kesken käyttöjärjestelmät, kuten käyttäjän lähdehakemistot.

Tästä kirjasta emme ole kovin kiinnostuneita jakaminen tiedostot eri versioita Linux, vaikka Linux-koneiden verkon tapauksessa tämä mahtava keino varmista, että hakemistoista on vain yksi kopio tärkeimmät ohjelmat ja jakaa se verkon eri koneille. Tämä on erityisen hyödyllistä levyttömille työasemille.

FHS-standardi määrittelee huipputason rakenteen, jossa on joukko vaadittuja alihakemistoja ja useita valinnaisia hakemistoja; tärkeimmät on esitetty taulukossa. 18.3.

Taulukko 18.3

Luettelo	Edellytetään?	Tarkoitus
/bin	Joo	Tärkeät järjestelmäbinaarit
/saapas	Joo	Järjestelmän käynnistämiseen tarvittavat tiedostot
/dev	Joo	Laitteet
/jne	Joo	Järjestelmätiedostot kokoonpanot
/Koti	Ei	Hakemistot käyttäjätiedostoille
/lib	Joo	Vakiokirjastot
/media	Joo	Tilaa irrotettavalle asennettavalle tietovälineelle, jossa on erilliset alihakemistot jokaiselle järjestelmän tukemalle mediatyypille
/mnt	Joo	Kätevä paikka laitteiden, kuten CD-ROM-levyjen ja flash-muistiasemien, väliaikaiseen asentamiseen
/valita	Joo	Lisäsovellusohjelmisto
/juuri	Ei	pääkäyttäjän tiedostot
/sbin	Joo	Tärkeitä järjestelmäbinääritiedostoja, joita tarvitaan järjestelmän käynnistysprosessin aikana
/srv	Joo	Vain luku -tiedot tämän järjestelmän tarjoamista palveluista
/tmp	Joo	Väliaikaiset tiedostot
/usr	Joo	Apuhierarkia. Perinteisesti tänne tallennetaan myös käyttäjätiedostoja, mutta nykyään tätä pidetään huonona tyylinä eikä tavalliselle käyttäjälle pitäisi antaa kirjoitusoikeutta tähän hakemistoon
/var	Joo	Muuttuvat tiedot, kuten lokitiedostot

Lisäksi voi olla muita lib-alkuisia hakemistoja, vaikka tämä ei ole yleistä. Tyypillisesti näet myös /lost+found -hakemiston (tiedostojärjestelmän palautusta varten fsck:n avulla) ja /proc-hakemiston, joka on pseudotiedostojärjestelmä, joka esittää käynnissä olevan järjestelmän. FHS-standardin nykyinen versio tukee vahvasti /proc-tiedostojärjestelmää, mutta sen läsnäoloa ei vaadita. /proc-järjestelmää koskevat yksityiskohdat jäävät suurelta osin tässä kirjassa käsiteltyjen aiheiden ulkopuolelle, vaikka olemme sisällyttäneet ne lyhyt arvostelu V Luku 3.

□ /bin - Sisältää binääritiedostoja, joita voivat käyttää sekä pääkäyttäjät että ei-root-käyttäjät ja jotka ovat tärkeitä toiminnalle yhden käyttäjän tilassa, jossa joitain muita hakemistorakenteita ei ehkä liitetä. Täältä löydät yleensä esimerkiksi ytimen komennot

ja kuten joukkue.

□ /boot - käytetään tiedostoille, joita tarvitaan Linux-järjestelmän käynnistyksen aikana. Usein tämä hakemisto on hyvin pieni, alle 10 Mt, ja se on usein erillinen osio. Tämä on erittäin hyödyllistä PC-pohjaisissa järjestelmissä, joissa on BIOS-rajoitukset aktiivinen osio, jonka on oltava levyn ensimmäisessä 2 tai 4 Gt:ssa. Kun käytät tätä hakemistoa erillisenä osiona, sinulla on enemmän joustavuutta muiden levyosioiden sijoittamisessa.

□ /dev - sisältää erityisiä laitetiedostoja, jotka on yhdistetty laitteistolaitteisiin. Esimerkiksi /dev/had liitetään ensimmäiseen IDE-asemaan.

□ /etc - sisältää asetustiedostoja. Perinteisesti joitain binäärejä löytyy täältä, mutta tämä ei enää päde useimpiin nykyaikaisiin Linux-järjestelmiin. Tunnetuin tiedosto /etc-hakemistossa on luultavasti passwd-tiedosto, joka sisältää käyttäjätietoja. Muita hyödyllisiä tiedostoja ovat fstab, jossa on luettelo asennusvaihtoehdoista; isännät, joissa on luettelo IP-osoitteista tietokoneiden nimiin ja httpd-hakemisto, joka sisältää Apache-palvelimen määritykset.

□ /home - hakemisto käyttäjätiedostoille. Yleensä jokaisella käyttäjällä tässä hakemistossa on yksi hakemisto, jonka nimi on sama kuin käyttäjän kirjautumisnimi, ja tämä on oletusarvoinen kirjautumishakemisto. Esimerkiksi rekisteröitymisen jälkeen käyttäjä rick löytää itsensä lähes varmasti /home/rick-hakemistosta.

□ /lib - Sisältää tärkeitä jaettuja kirjastoja ja ydinmoduuleja, erityisesti niitä, joita tarvitaan, kun järjestelmä käynnistyy yhden käyttäjän tilassa.

□ /media - suunniteltu huipputason hakemistoksi siirrettävien tietovälineiden liitoskohtahakemistojen tallentamiseen. Tavoitteena on pystyä poistamaan tarpeettomat ylätason hakemistot, kuten /cdrom ja /floppy.

□ /mnt on vain kätevä paikka tilapäisesti liittää muita tiedostojärjestelmiä. Perinteisesti jotkin jakelut ovat lisänneet alihakemistoja /mnt-hakemistoon for erilaisia laitteita, kuten /cdrom ja /floppy, mutta nykyinen etusija on sijoittaa ne /media-hakemistoon, jolloin /mnt palautetaan alkuperäiseen tarkoitukseen yhtenä ylimmän tason väliaikaisena asennuspaikkana.

□ /opt - lisäämiseen käytettyjen ohjelmistotoimittajien hakemisto ohjelmistosovelluksia lisätty perusjakaumaan. Jakelut eivät saa käyttää sitä vakiojakelun mukana tulevien ohjelmistojen tallentamiseen, vaan ne tulee jättää kolmansien osapuolten käyttöön. Tavallisesti toimittajat luovat alihakemistoja, joissa on omat nimensä ja alihakemistot, kuten /bin ja /lib, sovellukseensa liittyville tiedostoille.

Huomautus
Sopimuksen mukaan monet avoimen lähdekoodin Linux-paketit käyttävät /usr/local-hakemistoa asennukseen.

□ /root on pääkäyttäjän käyttämien tiedostojen hakemisto. Se ei ole osa /home-hakemistoa hakemistopuussa, koska se ei välttämättä liity yhden käyttäjän tilassa.

□ /sbin - käytetään yleensä vain käytettäviin komentoihin Järjestelmänvalvoja ja tarvitaan järjestelmän käynnistyksen aikana yhden käyttäjän tilassa. Täällä joukkueet asuvat

, Ja.

□ /srv - suunniteltu isännöimään vain luku -tilassa olevaa paikallista tietoa, mutta sitä ei käytetä tällä hetkellä laajalti.

□ /tmp - käytetään väliaikaisille tiedostoille. Yleensä, mutta ei aina, tyhjennetään, kun järjestelmä käynnistyy.

□ /usr - melko monimutkainen aputiedostojärjestelmä, joka sisältää yleensä kaikki komennot järjestelmän tyyppi ja kirjastoja, joita ei tarvita järjestelmän käynnistyksessä tai yhden käyttäjän tilassa. Hakemistossa on monia alihakemistoja, kuten /bin, /lib, /X11R6 ja /local.

Huomautus
Kun UNIX- ja Linux-järjestelmät ilmestyivät ensimmäisen kerran, /usr-hakemistossa oli myös alihakemistoja lokiin kirjaamista ja puskurointia varten. Sähköposti ja niin edelleen. Nyt kaikki nämä alihakemistot poistetaan usr-hakemistosta ja sijoitetaan var-hakemistoon. Tämän lähestymistavan etuna on, että /usr on nyt asennettavissa tiedostojärjestelmä, sen voivat jakaa muut verkon järjestelmät, ja se on vähemmän alttiina järjestelmän vaurioille, jotka pysäyttävät sen hallitsemattomasti, kuten sähkökatkos.

□ /var - Sisältää usein vaihtuvia tietoja, kuten taustatulostustiedostoja, sovelluslokitiedostoja ja sähköpostin taustatulostushakemistoja.

Tämän sivun osiot:

Nyt kun tiedät jotain C-standardista, katsotaanpa vaihtoehtoja, joita gcc-kääntäjä tarjoaa varmistaakseen C-standardin noudattamisen kirjoittamallasi kielellä. On kolme tapaa varmistaa, että C-koodisi on standardien mukainen ja siinä ei ole puutteita: vaihtoehdot, jotka hallitsevat standardin versiota, jota aiot noudattaa, määritelmät, jotka hallitsevat otsikkotiedostoja, ja varoitusvaihtoehdot, jotka käynnistävät tiukemman koodin tarkistuksen.

gcc:llä on valtava valikoima vaihtoehtoja, ja tässä tarkastellaan vain niitä, joita pidämme tärkeimpänä. Täydellinen luettelo vaihtoehdoista löytyy gcc online -man sivuilta. Keskustelemme myös lyhyesti joistakin #define direktiivivaihtoehdoista, joita voidaan käyttää; Yleensä ne tulee määrittää lähdekoodissa ennen #include-rivejä tai määritellä gcc-komentorivillä. Saatat yllättyä siitä, kuinka monta vaihtoehtoa on valita käytettävä standardi sen sijaan, että vain tarkistaisit lipun pakottaaksesi nykyisen standardin käyttöön. Syynä on se, että monet vanhemmat ohjelmat luottavat historialliseen kääntäjien käyttäytymiseen ja vaativat paljon työtä niiden päivittämiseksi uusimpiin standardeihin. Harvoin, jos koskaan, haluat päivittää kääntäjäsi, jotta se katkaisee käynnissä olevan koodin. Standardien muuttuessa on tärkeää pystyä toimimaan tiettyä standardia vastaan, vaikka se ei olisikaan standardin uusin versio.

Kääntäjävaihtoehdot standardien seurantaan

Std= - Tämä vaihtoehto mahdollistaa käytetyn standardin tarkemman hallinnan ja tarjoaa parametrin, joka määrittää täsmälleen vaaditun standardin. Seuraavat ovat tärkeimmät mahdolliset vaihtoehdot:

C89 - tukee C89-standardia;

Iso9899:1999 - tukee ISO-standardin C90 uusinta versiota;

Gnu89 - Säilytä C89-standardi, mutta salli joitain GNU-laajennuksia ja joitakin C99-toimintoja. Gcc:n versiossa 4.2 tämä vaihtoehto on oletusasetus.

Valinnat standardin seurantaan direktiiveissä määritellä

On vakioita (#defines), jotka voidaan määrittää komentorivillä tai määritelmiksi ohjelman lähdekoodissa. Ajattelemme näitä yleensä kääntäjän komentorivin käyttämisenä.

STRICT_ANSI__ - pakottaa ISO C -standardin käyttöön. Määritetään, kun -ansi-optio on määritetty kääntäjän komentorivillä.

POSIX_C_SOURCE=2 - Ottaa käyttöön IEEE Std 1003.1:ssä ja 1003.2:ssa määritellyt toiminnot. Palaamme näihin standardeihin myöhemmin tässä luvussa.

BSD_SOURCE - Mahdollistaa BSD-järjestelmien toiminnallisuuden. Jos ne ovat ristiriidassa POSIX-määritelmien kanssa, BSD-määritykset ovat etusijalla.

GNU_SOURCE - Mahdollistaa laajan valikoiman ominaisuuksia ja toimintoja, mukaan lukien GNU-laajennukset. Jos nämä määritelmät ovat ristiriidassa POSIX-määritelmien kanssa, jälkimmäiset ovat etusijalla.

Kääntäjän asetukset varoitustulosta varten

Nämä valinnat välitetään kääntäjälle komentoriviltä. Luettelemme jälleen vain tärkeimmät; täydellinen luettelo löytyy gcc:n online-käyttöoppaasta.

On yleinen käsitys, että GCC on suorituskyvyltään jälkeen muita kääntäjiä. Tässä artikkelissa yritämme selvittää, mitä GCC-kääntäjän perusoptimointeja tulisi soveltaa hyväksyttävän suorituskyvyn saavuttamiseksi.

Mitkä ovat oletusasetukset GCC:ssä?

(1) GCC:n oletusoptimointitaso on "-O0". Se ei selvästikään ole suorituskyvyn kannalta optimaalinen, eikä sitä suositella lopputuotteen kokoamiseen.
GCC ei tunnista arkkitehtuuria, jolla käännös suoritetaan, ennen kuin vaihtoehto ”-march=native” on ohitettu. Oletuksena GCC käyttää määrityksensä aikana määritettyä vaihtoehtoa. Saat selville GCC-kokoonpanon suorittamalla:

Tämä tarkoittaa, että GCC lisää "-march=corei7" valintoihin (ellei muuta arkkitehtuuria ole määritetty).
Useimmat GCC-kääntäjät x86:lle (perusversio 64-bittiselle Linuxille) lisäävät: "-mtune=generic -march=x86-64" annettuihin valintoihin, koska kokoonpanossa ei ole määritetty arkkitehtuuria määrittäviä vaihtoehtoja. Voit aina selvittää kaikki GCC:n käynnistyessä välitetyt vaihtoehdot sekä sen sisäiset asetukset komennolla:

Tämän seurauksena usein käytetty:

Käytettävän arkkitehtuurin määrittäminen on tärkeää suorituskyvyn kannalta. Ainoa poikkeus ovat ne ohjelmat, joissa kirjastotoimintojen kutsuminen vie lähes koko käynnistysajan. GLIBC voi valita optimaalisen toiminnon tietylle arkkitehtuurille ajon aikana. On tärkeää huomata, että staattisen linkityksen yhteydessä joillakin GLIBC-funktioilla ei ole versioita eri arkkitehtuureille. Eli dynaaminen kokoonpano on parempi, jos GLIBC-toimintojen nopeus on tärkeä..
(2) Oletuksena useimmat GCC-kääntäjät x86:lle 32-bittisessä tilassa käyttävät x87-liukulukumallia, koska ne on määritetty ilman "-mfpmath=sse". Vain jos GCC-kokoonpano sisältää "--with-mfpmath=sse":

kääntäjä käyttää oletusarvoisesti SSE-mallia. Kaikissa muissa tapauksissa on parempi lisätä "-mfpmath=sse" -vaihtoehto koontiversioon 32-bittisessä tilassa.
Eli usein käytetty:

Vaihtoehto ”-mfpmath=sse” on tärkeää 32-bittisessä tilassa! Poikkeuksena on kääntäjä, jonka kokoonpanossa on "--with-mfpmath=sse".

32-bittinen vai 64-bittinen tila?

32-bittistä tilaa käytetään yleensä vähentämään käytetyn muistin määrää ja siten nopeuttamaan sen kanssa työskentelyä (enemmän tietoa mahtuu välimuistiin).
64-bittisessä tilassa (32-bittiseen verrattuna) käytettävissä olevien rekisterien määrä yleinen käyttö kasvaa 6:sta 14:ään, XMM-rekisterit 8:sta 16:een. Lisäksi kaikki 64-bittiset arkkitehtuurit tukevat SSE2-laajennusta, joten 64-bittisessä tilassa ei tarvitse lisätä "-mfpmath=sse" -vaihtoehtoa.
On suositeltavaa käyttää 64-bittistä tilaa laskentatehtäviin ja 32-bittistä tilaa mobiilisovelluksiin.

Kuinka saada maksimaalinen suorituskyky?

Ei ole olemassa erityisiä vaihtoehtoja parhaan suorituskyvyn saavuttamiseksi, mutta GCC:llä on monia vaihtoehtoja, joita kannattaa kokeilla. Alla on taulukko, jossa on suositellut vaihtoehdot ja kasvuennusteet Intelin prosessorit Atom ja toinen sukupolvi Intel Core i7 koskien "-O2" vaihtoehtoa. Ennusteet perustuvat GCC-versiolla 4.7 kootun tietyn ongelmajoukon tulosten geometriseen keskiarvoon. Oletetaan myös, että kääntäjän konfigurointi suoritettiin x86-64 geneeriselle.
Ennuste mobiilisovellusten suorituskyvyn paranemisesta suhteessa "-O2":een (vain 32-bittisessä tilassa, koska se on mobiilisegmentin tärkein):

Ennuste parantuneesta suorituskyvystä laskentatehtävissä suhteessa "-O2":een (64-bittisessä tilassa):

-m64 -Ofast -flto	~17%
-m64 -Ofast -flto -mars=alkuperäinen	~21%
-m64 -Ofast -flto -march=alkuperäinen -funroll-silmukat	~22%

64-bittisen tilan etu 32-bittiseen verrattuna laskentatehtäviin “-O2 -mfpmath=sse”-vaihtoehdoilla on noin ~5 %.
Kaikki artikkelin tiedot ovat ennusteita, jotka perustuvat tietyn vertailuarvojoukon tuloksiin.
Alla on kuvaus artikkelissa käytetyistä vaihtoehdoista. Täydellinen kuvaus (englanniksi): http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html "

"-Ofast" on samanlainen kuin "-O3 -ffast-math" sisältää enemmän korkeatasoinen optimoinnit ja aggressiivisemmat optimoinnit aritmeettisiin laskelmiin (esimerkiksi todellinen uudelleenliittäminen)
"-flto" moduulien väliset optimoinnit
"-m32" 32-bittinen tila
"-mfpmath=sse" mahdollistaa XMM-rekisterien käytön todellisessa aritmetiikassa (todellisen pinon sijaan x87-tilassa)
"-funroll-loops" mahdollistaa silmukan purkamisen