Programkönyvtár HOGYAN

1.1. Magyar fordítás

A magyar fordítást Szalai Ferenc Attila készítette (2003.12.11). A lektorálást Daczi László végezte el (2004.03.01). A dokumentum legfrissebb változata megtalálható a Magyar Linux Dokumentációs Projekt honlapján.

3.1. Konvenciók

A fent leírt tulajdonságok megvalósításához a megosztott programkönyvtáraknak számos konvenciót és irányelvet követniük kell. Fontos megérteni a különbséget a programkönyvtárak nevei között, különösen a "so-név" és a "valódi név" között (és azok kapcsolatát). Azt is meg kell értened, hogy hova kell elhelyezni ezeket a programkönyvtárakat a fájlrendszerben.

3.2. Hogyan használjuk a programkönyvtárakat?

GNU glibc alapú rendszereken - ide tartozik az összes Linux rendszer - egy ELF bináris futtatható fájl elindítása automatikusan magával vonja a programbetöltő elindítását. Linux rendszereken ennek a betöltőnek a neve /lib/ld-linux.so.X (ahol X a verzió számot jelöli). Ez a betöltő keresi meg és tölti be az összes program által használt megosztott programkönyvtárat.

Azoknak az elérési utaknak a listája, amiben a betöltő a programkönyvtárakat keresi, az /etc/ld.so.conf fájlban található. Több Red Hat alapú terjesztésben a /usr/local/lib nem található meg ebben a fájlban. Ezt én hibának tekintem és az /usr/local/lib hozzáadást az /etc/ld.so.conf fájlhoz egy általános "javításnak" gondolom, ami minden Red Hat alapú rendszeren szükséges lehet.

Ha felül akarsz bírálni néhány eljárást egy programkönyvtárban, de meg akarod tartani az eredetit, akkor elhelyezheted a felülbírálandó programkönyvtárak nevét (.o fájlok) az /etc/ld.so.preload fájlban. Ezek az "előtöltött" programkönyvtárak elsőbbséget élveznek a standard programkönyvtárakkal szemben. Ez az előtöltő fájl általában átmenti foltozásra szolgál, és a terjesztések rendszerint nem tartalmaznak ilyeneket.

Nem igazán hatékony ezeket az elérési utakat megkeresni minden programindításakor. Ezért egy gyorstárazó módszert alkalmazunk. Az ldconfig(8) program alapértelmezésben az /etc/ld.co.conf fájlt olvasva beállítja a megfelelő szimbolikus hivatkozásokat a dinamikus hivatkozások könyvtáraiban (dynamic link directories) (így azok a konvenciókat fogják követni), és egy gyorstár-fájlt készít /etc/ld.so.cache néven. Ezt a gyorstárat használja aztán a többi program. Ez nagyon felgyorsítja a programkönyvtárak elérését. A következmény az, hogy az ldconfig parancsot minden esetben futtatni kell, ha új DLL-at adunk a rendszerhez vagy ha eltávolítjuk azt, vagy mikor átállítjuk a DLL programkönyvtárakat. Az ldconfig futtatás a leggyakoribb feladat, amit egy csomagkezelőnek el kell végeznie, mikor programkönyvtárat telepít. Indulásnál a dinamikus betöltő az /etc/ld.so.cache fájlt használja és utána tölti be a szükséges programkönyvtárakat.

Megjegyezzük, hogy a FreeBSD teljesen más fájlnevet használ ennek a gyorstárnak. FreeBSD-ben az ELF gyorstár a /var/run/ld-elf.so.hints, míg az a.out gyorstár a /var/run/ld.so.hints fájl. Az ldconfig(8) ezeket is frissíti, így ez az elnevezésbeli különbség csak néhány egzotikus esetben érdekes.

3.3. Környezeti változók

Számos környezeti változóval szabályozható az előbb bemutatott működés. Ezek a környezeti változók lehetővé teszik, hogy beavatkozzunk a programkönyvtárak betöltésének és használatának menetébe.

3.4. Megosztott programkönyvtárak készítése

Megosztott programkönyvtárat készíteni könnyű. Először egy tárgykód-fájlt kell készítenünk, amit a megosztott programkönyvtárba fogunk pakolni, a gcc -fPIC vagy -fpic kapcsolóinak segítségével. A -fPIC és -fpic opciók engedélyezik a "pozíció független kód" (position independent code) generálását, ami szükséges a megosztott programkönyvtárak készítéséhez (a különbségeket lásd alább). Az so-nevet a -Wl kapcsolóval adhatod meg a gcc-nek. A -Wl opció a szerkesztőnek (linker) szól (ebben az esetben a -soname linker opció) - a vesszők a -Wl után nem helyesírási hibák, és nem szabad szóközöket tenni közéjük. A megosztott programkönyvtár készítéséhez az alábbi formátumot használd:

gcc -shared -Wl,-soname,your_soname \
    -o library_name file_list library_list

Íme egy példa, ami két tárgykód-fájlt készít (a.o és b.o) aztán ezekből egy megosztott programkönyvtárat. Megjegyezzük, hogy ez a fordítás (compile) tartalmazza a hibakeresési (debug) információkat és a figyelmeztetések (warnings) generálását is, amik nem feltétlenül szükségesek a megosztott programkönyvtárak készítéséhez. A fordítás tárgykód-fájlokat állít elő (-c használata), és tartalmazza a szükséges -fPIC kapcsolót:

gcc -fPIC -g -c -Wall a.c
gcc -fPIC -g -c -Wall b.c
gcc -shared -Wl,-soname,libmystuff.so.1 \
    -o libmystuff.so.1.0.1 a.o b.o -lc

Íme néhány jó tanács:

• Ne használd a strip parancsot a keletkezett programkönyvtárra. Továbbá ne használd a -fomit-frame-pointer fordítási kapcsolót, hacsak nincs rá igazán szükséged. Az elkészült programkönyvtár működni fog ezekkel is, de a hibakeresőket használhatatlanná teszik.

• Használd a -fPIC vagy a -fpic kapcsolót a kód generáláskor. Mind a -fPIC, mind a -fpic kapcsolókkal készített kód célplatform-függő. A -fPIC választás mindig működik, de nagyobb kódot generálhat, mint a -fpic (könnyű megjegyezni: PIC nagy betűs, tehát nagyobb kódot generál) A -fpic opció használatával általában kisebb és gyorsabb kódot kapunk, de lesznek platformfüggő korlátozások, és számos globálisan látható szimbólum. A szerkesztő (linker) jelzi, hogy az így létrehozott tárgykód alkalmas-e megosztott programkönyvtár készítésére. Minden esetben, mikor bizonytalan vagy -fPIC kapcsolót válaszd, mert az mindig működik.

• Néhány esetben a "-Wl,-export-dynamic" gcc kapcsolók is szükségesek lehetnek a tárgykód-fájl létrehozásához. Normális esetben a dinamikus szimbólum táblázat csak azokat a szimbólumokat tartalmazza, amiket a dinamikus tárgykód-fájl használ. Ez a kapcsoló (mikor ELF típusú fájlt készítünk) hozzáadja az összes szimbólumot a dinamikus szimbólum táblázathoz (lásd ld(1) több információért). Ezt a kapcsolót kell használnod, amikor vannak "visszafelé függőségek" (reverse dependences), úgy mint amikor egy DL programkönyvtárban fel ne oldott szimbólumok vannak, amiket a hagyomány szerint definiálni kell abban a programban, amelyik be szeretné tölteni ezeket a programkönyvtárakat. A "visszafelé függőség" működéséhez a főprogramnak dinamikusan elérhetvé kell tennie ezeket a szimbólumokat. Megjegyezzük, hogy használhatod a "-rdynamic" kapcsolót a "-Wl,export-dynamic" helyett, ha csak Linux rendszeren dolgozol, de az ELF dokumentációja szerint az "-rdynamic" kapcsoló nem mindig működik gcc-nél nem Linux-alapú rendszereken.

Fejlesztés közben az egyik tipikus probléma annak a programkönyvtárnak a módosítása, amit más programok is használnak -- és nem szeretnéd, hogy a többi program is a "fejlesztési" programkönyvtárat használja, csak egy kiszemelt alkalmazást szeretnél tesztelni vele. Az ld "rpath" szerkesztési (link) opcióját kell használnod ebben az esetben, ami szerkesztési időben meghatározza a futásidejű programkönyvtár (runtime library) keresési útvonalát egy adott programra. A gcc-t az rpath opcióval az alábbi módon használhatod:

-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

Ha ezt az opciót használod amikor elkészíted (build) a programkönyvtár kliens programját, akkor nem kell azzal vacakolnod, hogy a LD_LIBRARY_PATH-al elkerüld a összeütközéseket vagy, hogy más módszerekkel elrejtsd a programkönyvtárat.

3.5. Megosztott programkönyvtárak telepítése és használata

Ha már készítettél megosztott programkönyvtárat, nyilván használni is akarod. Az egyik lehetőség, hogy egyszerűen a szabványos könyvtárak egyikébe másolod a programkönyvtárat (pl. /usr/lib) és lefuttatod a ldconfig(8)-ot.

Először is készítened kell egy megosztott programkönyvtárat valahol. Aztán be kell állítanod a szükséges szimbolikus hivatkozásokat (symbolic links), különösen a so-névről a valódi névre (akárcsak a verziómentes so-névről mutatót - ami a so-név ami ".so"-val végződik - azoknak a felhasználóknak, akik nem határoznak meg verziót egyáltalán). Az egyszerűbb megoldás, hogy az alábbi parancsot futtatod:

ldconfig -n directory_with_shared_libraries

Végül, amikor fordítod a programodat, meg kell mondanod a szerkesztőnek azokat a statikus és megosztott programkönyvtárakat, amiket használni akarsz. Erre használd a -l és -L kapcsolókat.

Ha nem tudod, vagy nem akarod telepíteni a programkönyvtáradat egy standard helyre (például nincs jogod módosítani az /usr/lib könyvtárat), akkor más megoldást kell választanod. Ebben az esetben telepítened kell a programkönyvtárat valahova, aztán elég információt kell adnod a programodnak, hogy megtalálja a programkönyvtárat. Többféle mód is létezik erre. Használhatod a gcc -L kapcsolóját egyszerűbb esetekben. Használhatod a "rpath"-os megoldást (lásd feljebb), különösen, ha csak egy speciális program használja a programkönyvtárat, ami a "nem-standard" helyen van. Használhatsz környezeti változókat is, hogy kézben tartsd a dolgokat. Az LD_LIBRARY_PATH környezeti változó használhatod, ami egy kettősponttal elválasztott listája azoknak az elérési utaknak, ahol a megosztott programkönyvtárakat keressük, mielőtt a szokásos helyeken próbálkoznánk. Ha bash-t használsz indíthatod a my_program-ot így:

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH  my_program

Ha csak néhány kiválasztott függvényt akarsz módosítani, akkor megteheted, hogy készítesz egy módosító tárgykód-fájlt, és beállítod a LD_PRELOAD környezeti változót. A függvények ebben a tárgykódban csak azokat a függvényeket fogják felülírni, amik a programkönyvtárban szerepelnek (a többit nem változtatja meg).

Rendszerint nyugodtan frissítheted a programkönyvtárakat, ha API változás volt a programkönyvtár készítője feltételezhetően megváltoztatta a so-nevet. Ezért lehet több programkönyvtár egyszerre egy rendszeren, a megfelelő lesz kiválasztva mindegyik programhoz. Ha a program mégis összeomlik, a programkönyvtár frissítésének hatására, ráveheted, hogy használja a régebbi programkönyvtár-verziót. Ehhez másold a régi programkönyvtárat vissza a rendszerre valahova. Változtasd meg a program nevét (legyen a régi név ".orig" kiterjesztéssel), majd készíts egy kis indító-szkriptet, ami visszaállítja a régi programkönyvtárat a programnak. A régi programkönyvtárat elhelyezheted egy saját speciális helyre, ha akarod, használhatod a számozási konvenciót, hogy több verzió is lehessen ugyanabban a könyvtárban. Íme egy minta indító-szkript:

#!/bin/sh export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH exec /usr/bin/my_program.orig $*

Kérlek ne használd ezt, amikor a saját programodat készíted. Próbálj meggyőződni arról, hogy a programkönyvtáraid vagy visszamenőlegesen kompatibilisek, vagy növelted a verzió számot a so-névben minden esetben, ha nem kompatibilis változást végeztél. Ez csak egy vészmegoldás a legrosszabb esetekre.

Egy program által használt megosztott programkönyvtárak listáját az ldd(1) programmal kaphatod meg. Tehát például, ha az ls program által használt megosztott programkönyvtárakat szeretnéd látni, írd a következőt:

ldd /bin/ls

Megkapod azoknak a so-nevek listáját, amiktől a program függ, a könyvtárral (directory) együtt, amiben azok a nevek feloldhatóak. Gyakorlatilag minden esetben legalább két függőséged lesz:

• /lib/ld-linux.so.N (ahol N 1 vagy több, rendszerint legalább 2). Ez a programkönyvtár ami betölti az összes többit.

• libc.so.N (ahol N 6 vagy több). Ez a C programkönyvtár. Minden más nyelv is igyekszik a C programkönyvtárat használni (ahelyett, hogy sajátot valósítana meg), így a legtöbb program legalább ezt az egyet használja.

3.6. Inkompatibilis programkönyvtárak

Abban az esetben, ha egy programkönyvtár új változata binárisan inkompatibilis a régivel, akkor a so-nevet meg kell változtatni. C-ben négy alapvető oka lehet annak, hogy egy programkönyvtár inkompatibilissé válik:

1. A függvény viselkedése megváltozik, nem egyezik meg az eredeti specifikációval.

2. Nyilvános adatelemek megváltoztak (kivétel: hozzáadott opcionális elemek a struktúrák végén nem okoznak problémát, ha ezeket a struktúrákat csak a programkönyvtár foglalja le)

3. Nyilvános függvényt eltávolítottak.

4. A nyilvános függvény interfésze megváltozott.

Ha ezeket el tudod kerülni, akkor a programkönyvtáraid binárisan kompatibilisek lesznek. Más szóval az alkalmazás bináris interfésze (Application Binary Interface - ABI) kompatibilis maradhat, ha a fenti típusú változtatásokat elkerülöd. Például, hozz létre új függvényeket, de ne töröld a régieket. Hozzáadhatsz új elemeket a struktúrákhoz, de csak akkor, ha meggyőződtél róla, hogy a régi programok nem lesznek érzékenyek erre a változásra. Csak a struktúra végére adj új elemeket, és csak a programkönyvtár (és nem az alkalmazás) által elfoglalt struktúrákban teheted ezt meg. Az új elemek legyenek opcionálisak (vagy a programkönyvtár töltse ki őket) stb. Figyelem: valószínűleg nem tudod kiterjeszteni a struktúráidat, ha a felhasználók tömbökben használják azokat.

C++ (illetve egyéb fordítási időben használatos sablonokat (template) vagy "compiled dispatched" eljárásokat támogató nyelvek) esetén a helyzet kicsit trükkösebb. A fenti megkötéseket mind figyelembe kell venni, és meg sok minden mást is. Ennek oka, hogy néhány információ rejtve (under the covers) került megvalósításra a lefordított kódban. Ennek eredménye nem nyilvánvaló, ha nem tudod, hogy tipikusan, hogy szokták a C++-t megvalósítani. Szigorúan véve ezek nem "új" dolgok, csak arról van szó, hogy C++ használhat adatstruktúrákat úgy, hogy az a meglepetés erejével hathat. Az alábbi egy - a Troll Tech's Technical FAQ alapján összeállított (feltehetőleg hiányos) listája azoknak a dolgoknak, amit nem tehetsz meg C++-ban, ha meg akarod tartani a kompatibilitást.

1. virtuális függvények újra megvalósításának hozzáadása, (hacsak nem vagy benne biztos, hogy a régi programok az eredeti megvalósítást fogják használni). Mert a fordító már fordítási időben (nem csatolási (link) időben) kiértékeli a SuperClass::virtualFunction() függvényhívást.

2. virtuális tagfüggvény hozzáadása vagy törlése, mert ez megváltoztathatja a minden alosztály vtbl-jének méretét és szerkezetét.

3. bármilyen olyan adattag típusának megváltoztatása vagy törlése, amit inline tagfüggvények érnek el.

4. osztályhierarchia megváltoztatása, kivéve az új levelek hozzáadását.

5. privát adattag hozzáadása vagy elvétele, mert ez megváltoztatja a méretét és szerkezetét minden alosztálynak.

6. public vagy protected tagsági függvények eltávolítása, hacsak nem inline típusúak.

7. public vagy protected tagfüggvény inline típusúvá tenni.

8. módosítani a inline típusú függvények működését, kivéve ha régi változat továbbra is működik.

9. a tagsági függvények hozzáférési jogának (public, protected vagy private) megváltoztatása egy hordozható programban, mert néhány fordító hozzáadja a hozzáférési jogot a függvénynévhez.

Ez a hosszú lista is jól mutatja, hogy a C++ programkönyvtár fejlesztőknek bizonyos esetekben sokkal jobban meg kell tervezniük a dolgokat, hogy megtartsák a bináris kompatibilitást. Szerencsére Unix-szerű rendszereken (a Linuxot is beleértve) egy programkönyvtárad több verziója lehet egyszerre betöltve. Így amíg van elég lemezterület, a felhasználók futtathatnak "régi" programokat, amik régi programkönyvtárakat használnak.

4.1. dlopen()

A dlopen(3) függvény megnyitja a programkönyvtárat és előkészíti használatra. C prototípusa az alábbi:

void * dlopen(const char *filename, int flag);

Ha filename "/"-el kezdődik (például egy abszolút elérési út), dlopen() így fogja használni ezt (nem fogja megkeresi a programkönyvtárat). Egyéb esetekben a dlopen() az alábbi sorrendben keresi a programkönyvtárakat:

1. Könyvtárak kettősponttal elválasztott listája a felhasználó LD_LIBRARY_PATH környezeti változójában.

2. Az /etc/ld.so.cache fájlban található programkönyvtárak listájában, amit az /etc/ld.so.conf-ból generáltunk.

3. /lib, aztán /usr/lib. Megjegyezzük, hogy ez pont a fordítottja a régi a.out betöltő viselkedésének. A régi a.out betöltő először az /usr/lib könyvtárban keresett aztán a /lib könyvtárban (lásd ld.so(8) man oldal). Normális körülmények között ez nem számít, a programkönyvtárnak az egyik vagy a másik könyvtárban kellene lennie (sohasem mindkettőben), mivel azonos névvel rendelkező különböző programkönyvtárak katasztrófát okoznak.

Ha a programkönyvtár tartalmaz egy _init nevű public eljárást, akkor az abban lévő kód lefut, mielőtt a dlopen visszatér. Ezt a saját program inicializációs eljárásnak használhatod. Ugyanakkor a programkönyvtáraknak nem kötelező _init és _fini nevű eljárásokat tartalmazniuk. Ez a mechanizmus elavult és nem kívánatos működést eredményezhet. Helyette a programkönyvtáraknak __attribute__((constructor)) és __attribute__((destructor)) függvény attribútumokkal megjelölt eljárásokat kellene használniuk (feltéve, hogy gcc-t használsz). További részleteket a "Programkönyvtár konstruktor és destruktor függvények" fejezetben olvashatsz erről.

4.2. dlerror()

Hibákat a dlerror() függvényhívással lehet kezelni. Ez visszatér az utolsó dlopen(), dlsym() vagy dlclose() függvényhívás okozta hibát leíró karaktersorozattal. Kellemetlen, hogy a dlerror() meghívása után a többi dlerror() függvényhívás NULL-al fog visszatárni mindaddig, amíg egy másik hiba nem keletkezik.

4.3. dlsym()

Nincs értelme betölteni egy DL programkönyvtárat, ha nem tudod használni. A DL programkönyvtár használatának alaprutinja a dlsym(3). Ez szimbólumokat keres a már megnyitott programkönyvtárakban. A függvénydefiníció így néz ki:

void * dlsym(void *handle, char *symbol);

A handle a dlopen által visszaadott érték, a symbol egy NIL-el végződő karaktersorozat. Az a jó, ha a dlsym eredményét nem tárolod void* mutatóban, ellenkező esetben minden alkalommal ki kell osztanod (cast). (és kevés információt adsz azoknak az embereknek, akik megpróbálják megérteni a programodat)

A dlsym() NULL-al tér vissza, ha a szimbólumot nem találta. Ha előre tudod, hogy a szimbólum értéke soha nem NULL vagy zero, akkor ez rendben van, de potenciális veszélyforrás minden más esetben. Ugyanis, ha kapsz egy NULL-t nem tudod eldönteni, hogy a szimbólumot nem találta a dlsym, vagy az értéke éppen NULL. A szokásos megoldás ilyenkor, hogy először meghívod a dlerror()-t (azért, hogy eltüntess, minden hibát ami létezik), aztán a dlsym()-et hívod a szimbólum keresésére, végül újra a dlerror()-t, hogy lásd történt-e hiba. A kódrészlet valahogy így nézhet ki:

dlerror(); /* clear error code */ s = (actual_type) dlsym(handle, symbol_being_searched_for); if ((err = dlerror()) != NULL) { /* handle error, the symbol wasn't found */ } else { /* symbol found, its value is in s */ }

4.4. dlclose()

A dlopen() párja a dlclose(), ami bezárja a DL programkönyvtárat. A DL programkönyvtár kapcsolatszámlálókat (link counts) hoz létre a dinamikus fájlkezelőkhöz, így a dinamikus programkönyvtár mindaddig nem lesz felszabadítva, amíg a dlclose-t nem hívták meg annyiszor, ahányszor a dlopen-t. Így nem okoz problémát, ha ugyanaz a program ugyanazt a programkönyvtárat többször tölti be. Ha a programkönyvtár valóban felszabadul a régi programkönyvtárak esetén a _fini függvénye meghívódik (ha létezik). A _fini már egy elavult mechanizmus és nem ajánlatos a használata. Helyette a programkönyvtáraknak az __attribute__((constructor)) és __attribute__((destructor)) függvényattribútumukkal ellátott eljárásit kell használni. További részleteket a "Programkönyvtár konstruktor és destruktor függvények" fejezetben olvashatsz erről. Megjegyezzük, hogy a dlclose() 0-val tér vissza siker, és nem nullával hiba esetén. Néhány Linux kézikönyv oldal nem tesz említést erről.

4.5. DL programkönyvtár példa

Íme egy példa a dlopen(3) kézikönyvből. Ez a példa betölti a math programkönyvtárat és kiírja a 2.0 koszinuszát. Ellenőrzi a hibákat, minden lépésnél (ami melegen ajánlott):

#include <stdlib.h> #include <stdio.h> #include <dlfcn.h> int main(int argc, char **argv) { void *handle; double (*cosine)(double); char *error; handle = dlopen ("/lib/libm.so.6", RTLD_LAZY); if (!handle) { fputs (dlerror(), stderr); exit(1); } cosine = dlsym(handle, "cos"); if ((error = dlerror()) != NULL) { fputs(error, stderr); exit(1); } printf ("%f\n", (*cosine)(2.0)); dlclose(handle); }

Ha ez a program a "foo.c" állományban van, akkor az alábbi paranccsal fordíthatod le:

gcc -o foo foo.c -ldl

5.1. nm utasítás

Az nm(1) utasítás megmutatja milyen szimbólumok találhatóak egy adott programkönyvtárban. Mind statikus, mind megosztott programkönyvtárakra működik. Egy adott programkönyvtárra az nm(1) a szimbólumok neveit, és minden szimbólum típusát és értékét képes megmutatni. Azt is képes meghatározni, hogy a forráskódban hol volt a szimbólum definiálva (fájlnév és sor), ha ezt az információt tartalmazza a programkönyvtár (lásd a -l kapcsolót).

A szimbólum típusok kicsit több magyarázatot igényelnek. A típust egy karakter jelzi. A kisbetű azt jelenti, hogy a szimbólum lokális, míg a nagybetű azt, hogy globális (külső). A tipikus szimbólum típusok a következők: T (normál definíció a kód részben), D (inicializált adat szekció), B (nem inicializált adat szekció), U (nem definiált; a szimbólumot használja a programkönyvtár de nincs definiálva abban), és W (waek; ha más programkönyvtár szintén definiálja ezt a szimbólumot, és az a definíció elrejti azt).

Ha tudod a függvény nevét, de nem emlékszel, hogy melyik programkönyvtárban van definiálva, akkor a nm "-o" kapcsolóját (ami minden sor elé odarakja az fájlnevet) használhatod a grep-el együtt, hogy megtaláld a programkönyvtár nevét. Bourne héjban kereshetsz minden programkönyvtárban a /lib, /usr/lib, /usr/local/lib és azok alkönyvtáraiban a "cos"-ra az alábbiak szerint:

nm -o /lib/* /usr/lib/* /usr/lib/*/* \ /usr/local/lib/* 2> /dev/null | grep 'cos$'

Sokkal több információt található az nm-ről a "info" dokumentumában (info:binutils#nm).

5.2. Programkönyvtár konstruktor és destruktor függvények

A programkönyvtárak megvalósíthatnak nyilvános inicializációs és cleanup függvényeket, a gcc __attribute__((constructor)) és __attribute__((destructor)) függvény attribútumait használva. További információt a gcc info oldalain találsz erről. A konstruktor eljárások a dlopen visszatérése előtt (vagy a main() előtt, ha a programkönyvtár betöltési időben kerül megnyitásra) hívódnak meg. A destruktor eljárások a dlclose visszatérése előtt (vagy a exit() vagy a main() befejezésekor, ha a programkönyvtár betöltési időben került megnyitásra) hívódnak meg. A C prototípusa ezeknek a függvényeknek a következő:

void __attribute__ ((constructor)) my_init(void); void __attribute__ ((destructor)) my_fini(void);

A megosztott programkönyvtárakat tilos a gcc "-nostartfiles" vagy "-nostdlib" kapcsolóival fordítani. Ha ezeket használjuk a konstruktor/destruktor eljárások nem fognak lefutni (hacsak valami speciális nem történik).

5.3. Megosztott programkönyvtárak, mint szkriptek

Jó dolog, hogy a GNU betöltő engedélyezi, hogy a programkönyvtárak szöveges fájlok is lehetnek, amiket egy speciális szkript nyelven kell írni a szokásos programkönyvtár-formátum helyett. Ez hasznos például programkönyvtárak közvetett összekapcsolása esetén. Példaként álljon itt a rendszerem /usr/lib/libc.so fájlja:

/* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

További információt találsz erről a ld texinfo dokumentációjában a linker scripts szekcióban (ld parancs nyelv). Általános információ a info:ld#Options and info:ld#Commands, fejezetben. Az utasítások pedig a info:ld#Option Commands-ban.

5.4. Szimbólum verziók és verzió szkriptek

A külső függvényekre történő hivatkozások jellemzően egy szükségszerű bázishoz vannak kötve, amelyek közül nem mindegyik kötődik a külső függvényhez, az alkalmazás indulásakor. (Typically references to external functions are bound on an as-needed basis, and are not all bound when the application starts up.) Ha a megosztott programkönyvtár régi, az igényelt interfésze hiányozhat, amikor az alkalmazás megpróbálja használni azt. Ez azonnali és váratlan hibát okozhat.

A probléma megoldható a szimbólumok verzióval való megjelölésével, és a verzió-szkript csatolásával. Szimbólum verziók használatával a felhasználó figyelmeztetést kap, ha olyan programot indít el, amely túl régi programkönyvtárat akar használni. Többet tudhatsz meg az ld kézkönyvből, a http://www.gnu.org/manual/ld-2.9.1/html_node/ld_25.html honlapon.

5.5. GNU libtool

Ha olyan alkalmazást készítesz amit több rendszerre szeretnél használni, akkor javasolt a GNU libtool használata a programkönyvtár fordításához és telepítéséhez. A GNU libtool egy általános programkönyvtár-készítést támogató szkript. A Libtool elrejti a megosztott programkönyvtárak bonyolultságát egy konzisztens és hordozható interfész mögé. A Libtool hordozható interfészt biztosít a tárgykód fájlok készítéséhez, a programkönyvtárak (statikus és megosztott), a futtatható fájlokhoz csatolásához, a futtatható fájlok hibakereséséhez, a programkönyvtárak és futtatható fájlok telepítéséhez. Tartalmaz továbbá egy libltdl programkönyvtárat, ami egy hordozható csatolófelület a dinamikusan betölthető programkönyvtárakhoz. Többet tudhatsz meg a http://www.gnu.org/software/libtool/manual.html honlapon található dokumentációból.

5.6. Szimbólumok eltávolítása

A generált fájlokban található szimbólumok hasznosak hibakeresésnél, de sok helyet foglalnak. Ha helyre van szükséged, akkor csökkentheted a szimbólumok számát.

A legjobb eljárás először a tárgykódokat szimbólumokkal generálni és a tesztelést és hibakaresést ezekkel végezni, sokkal könnyebb így. Azután, mikor a program már alaposan tesztelve van a strip(1)-et használhatod a szimbólumok eltávolítására. A strip(1) utasítás sok lehetőséget ad arra, hogy meghatározd milyen szimbólumokat akarsz eltávolítani. További részletekért olvasd a dokumentációt.

Egy másik lehetőség a GNU ld "-S" és "-s" kapcsolóinak használata. Az "-S"'mellőzi a hibakereséshez szükséges szimbólumokat (de nem az összes szimbólumot). A "-s" pedig az összes szimbólum információt kihagyja a kimeneti fájlból. Használhatod ezeket a kapcsolókat a gcc-n keresztül is a "-Wl,-S" és "-Wl,-s" formában. Ha sosem akarsz szimbólumokat, akkor ezek a kapcsolók megfelelőek, használd őket. De ez a kevésbé rugalmas megoldás.

5.7. Nagyon kicsi futtatható fájlok

Egy igen hasznos leírást találhatsz a Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux honlapon. Ez leírja, hogyan készíthetsz igazán parányi futtatható fájlokat. Őszintén szólva a legtöbb ott található trükk nem használható normál esetben, de jól mutatják, hogy működik az ELF igazából.

5.8. C++ vs. C

Semmi akadálya annak, hogy C++ programból C programkönyvtári függvényeket hívj meg. A C++ kódban a C függvény extern "C"-nek kell definiálni. Ellenkező esetben a szerkesztő (linker) nem fogja megtalálni a C függvényt. A C++ fordító "szétszedi" a C++ függvények neveit (például típusazonosítás céljából), jelezni kell neki, hogy egy adott függvényt, mint C függvényt kell hívnia (és így ezt a szétszedést nem kell használni).

Ha olyan programkönyvtárat írsz amit C és C++-ból is hívni kell, akkor ajánlott a megfelelő header fájlba elhelyezd a 'extern "C"'utasítást azért, hogy ezt a tulajdonságot automatikusan biztosítsd a felhasználóknak. Ha ezt kombinálod a szokásos #ifndef-el a fájl elején, hogy elkerüld a header fájl újrafeldolgozását, akkor ez azt jelenti, hogy egy tipikus header fájl, ami C és C++-ban is használható (neve legyen mondjuk foobar.h) így néz ki:

/* Explain here what foobar does */ #ifndef FOOBAR_H #define FOOBAR_H #ifdef __cplusplus extern "C" { #endif ... header code for foobar goes here ... #ifdef __cplusplus } #endif #endif

5.9. A C++ inicializáció felgyorsítása

A KDE fejlesztők jelezték, hogy nagy grafikus C++ alkalmazások indulása sokáig tart. Ez részben a sok újra allokációnak köszönhető. Létezik néhány megoldás a problémára. További információt Waldo Bastian: Making C++ ready for the desktop című írásában olvashatsz.

5.10. Linux Standard Base (LSB)

A Linux Standard Base (LSB) projekt célja, hogy olyan szabványokat dolgozzon ki és népszerűsítsen, amelyek növelik a kompatibilitást a Linux terjesztések között, és lehetővé teszik az alkalmazások futtatását minden ennek megfelelő Linux rendszeren. A projekt honlapja a http://www.linuxbase.org webhelyen érhető el.

Egy szép cikk jelent meg George Kraft IV (IBM Linux Technology Center senior szoftvermérnök) tollából 2002 októberében arról, hogyan fejlesszünk LSB kompatibilis alkalmazásokat: Developing LSB-certified applications: Five steps to binary-compatible Linux applications. Természetesen a kódot úgy kell megírni, hogy egy standardizált réteget használjon, ha azt akarod, hogy a program hordozható legyen. Továbbá a LSB eszközöket biztosít a C/C++ az alkalmazás készítőknek, a programok LSB kompatibilitásának ellenőrzésére. Ezek az eszközök kihasználják a szerkesztő (linker) néhány tulajdonságát, és néhány speciális programkönyvtárat használnak a szükséges ellenőrzéseknek elvégzésére. Nyilvánvalóan telepítened kell ezeket az eszközöket, ha el akarod végezni ezeket az ellenőrzéseket. Az LSB honlapján megtalálhatók. Ezt követően egyszerűen a "lsbcc" kell használnod, mint C/C++ fordítót (az lsbcc belsőleg készít egy csatolási környezetet, ami jelezni fogja, ha bizonyos LSB szabályok sérülnek):

$ CC=lsbcc make myapplication (or) $ CC=lsbcc ./configure; make myapplication

Az lsbappchk programot arra használhatod, hogy ellenőrizd a program valóban csak az LSB által standardizált függvényeket használja:

$ lsbappchk myapplication

Az LSB csomagolási útmutatót is követned kell (pl. használj RPM v3-at, használj LSB által meghatározott csomagneveket, és az add-on szoftvereket az /opt-ba kell telepítened alapértelmezetten). További információkat a cikkben és az LSB honlapján találsz.

6.1. libhello.c fájl

/* libhello.c - demonstrate library use. */ #include <stdio.h> void hello(void) { printf("Hello, library world.\n"); }

6.2. libhello.h fájl

/* libhello.h - demonstrate library use. */ void hello(void);

6.3. demo_use.c fájl

/* demo_use.c -- demonstrate direct use of the "hello" routine */ #include "libhello.h" int main(void) { hello(); return 0; }

6.4. script_static fájl

#!/bin/sh # Static library demo # Create static library's object file, libhello-static.o. # I'm using the name libhello-static to clearly # differentiate the static library from the # dynamic library examples, but you don't need to use # "-static" in the names of your # object files or static libraries. gcc -Wall -g -c -o libhello-static.o libhello.c # Create static library. ar rcs libhello-static.a libhello-static.o # At this point we could just copy libhello-static.a # somewhere else to use it. # For demo purposes, we'll just keep the library # in the current directory. # Compile demo_use program file. gcc -Wall -g -c demo_use.c -o demo_use.o # Create demo_use program; -L. causes "." to be searched during # creation of the program. Note that this command causes # the relevant object file in libhello-static.a to be # incorporated into file demo_use_static. gcc -g -o demo_use_static demo_use.o -L. -lhello-static # Execute the program. ./demo_use_static

6.5. script_shared fájl

#!/bin/sh # Shared library demo # Create shared library's object file, libhello.o. gcc -fPIC -Wall -g -c libhello.c # Create shared library. # Use -lc to link it against C library, since libhello # depends on the C library. gcc -g -shared -Wl,-soname,libhello.so.0 \ -o libhello.so.0.0 libhello.o -lc # At this point we could just copy libhello.so.0.0 into # some directory, say /usr/local/lib. # Now we need to call ldconfig to fix up the symbolic links. # Set up the soname. We could just execute: # ln -sf libhello.so.0.0 libhello.so.0 # but let's let ldconfig figure it out. /sbin/ldconfig -n . # Set up the linker name. # In a more sophisticated setting, we'd need to make # sure that if there was an existing linker name, # and if so, check if it should stay or not. ln -sf libhello.so.0 libhello.so # Compile demo_use program file. gcc -Wall -g -c demo_use.c -o demo_use.o # Create program demo_use. # The -L. causes "." to be searched during creation # of the program; note that this does NOT mean that "." # will be searched when the program is executed. gcc -g -o demo_use demo_use.o -L. -lhello # Execute the program. Note that we need to tell the program # where the shared library is, using LD_LIBRARY_PATH. LD_LIBRARY_PATH="." ./demo_use

6.6. demo_dynamic.c fájl

/* demo_dynamic.c -- demonstrate dynamic loading and use of the "hello" routine */ /* Need dlfcn.h for the routines to dynamically load libraries */ #include <dlfcn.h> #include <stdlib.h> #include <stdio.h> /* Note that we don't have to include "libhello.h". However, we do need to specify something related; we need to specify a type that will hold the value we're going to get from dlsym(). */ /* The type "simple_demo_function" describes a function that takes no arguments, and returns no value: */ typedef void (*simple_demo_function)(void); int main(void) { const char *error; void *module; simple_demo_function demo_function; /* Load dynamically loaded library */ module = dlopen("libhello.so", RTLD_LAZY); if (!module) { fprintf(stderr, "Couldn't open libhello.so: %s\n", dlerror()); exit(1); } /* Get symbol */ dlerror(); demo_function = dlsym(module, "hello"); if ((error = dlerror())) { fprintf(stderr, "Couldn't find hello: %s\n", error); exit(1); } /* Now call the function in the DL library */ (*demo_function)(); /* All done, close things cleanly */ dlclose(module); return 0; }

6.7. script_dynamic fájl

#!/bin/sh # Dynamically loaded library demo # Presume that libhello.so and friends have # been created (see dynamic example). # Compile demo_dynamic program file into an object file. gcc -Wall -g -c demo_dynamic.c # Create program demo_use. # Note that we don't have to tell it where to search for DL libraries, # since the only special library this program uses won't be # loaded until after the program starts up. # However, we DO need the option -ldl to include the library # that loads the DL libraries. gcc -g -o demo_dynamic demo_dynamic.o -ldl # Execute the program. Note that we need to tell the # program where get the dynamically loaded library, # using LD_LIBRARY_PATH. LD_LIBRARY_PATH="." ./demo_dynamic