
Programknyvtr HOGYANDavid A. Wheeler

v1.20, 2003. prilis 11.

   Ez a HOGYAN azoknak a programozknak kszlt, akik programknyvtrakat
   szeretnnek hasznlni Linuxon. sszefoglalja a programknyvtrak
   ksztst s hasznlatt. Egyarnt tartalmazza a statikus (static),
   megosztott (shared), valamint a dinamikusan betlthet (dynamically
   loaded) programknyvtrakkal kapcsolatos ismereteket.
     _________________________________________________________________

   Tartalomjegyzk
   1. [1]Bevezets

        1.1. [2]Magyar fordts

   2. [3]Statikus programknyvtrak
   3. [4]Megosztott programknyvtrak

        3.1. [5]Konvencik
        3.2. [6]Hogyan hasznljuk a programknyvtrakat?
        3.3. [7]Krnyezeti vltozk
        3.4. [8]Megosztott programknyvtrak ksztse
        3.5. [9]Megosztott programknyvtrak teleptse s hasznlata
        3.6. [10]Inkompatibilis programknyvtrak

   4. [11]Dinamikusan betlthet (Dynamically Loaded; DL)
          programknyvtrak

        4.1. [12]dlopen()
        4.2. [13]dlerror()
        4.3. [14]dlsym()
        4.4. [15]dlclose()
        4.5. [16]DL programknyvtr plda

   5. [17]Egyb

        5.1. [18]nm utasts
        5.2. [19]Programknyvtr konstruktor s destruktor fggvnyek
        5.3. [20]Megosztott programknyvtrak, mint szkriptek
        5.4. [21]Szimblum verzik s verzi szkriptek
        5.5. [22]GNU libtool
        5.6. [23]Szimblumok eltvoltsa
        5.7. [24]Nagyon kicsi futtathat fjlok
        5.8. [25]C++ vs. C
        5.9. [26]A C++ inicializci felgyorstsa
        5.10. [27]Linux Standard Base (LSB)

   6. [28]Tovbbi pldk

        6.1. [29]libhello.c fjl
        6.2. [30]libhello.h fjl
        6.3. [31]demo_use.c fjl
        6.4. [32]script_static fjl
        6.5. [33]script_shared fjl
        6.6. [34]demo_dynamic.c fjl
        6.7. [35]script_dynamic fjl

   7. [36]Tovbbi informci
   8. [37]Copyright and License

1. Bevezets

Ez a HOGYAN programozknak kszlt, s sszefoglalja, hogyan kszthetsz s
hasznlhatsz programknyvtrakat Linuxon, a GNU eszkzkszlet
felhasznlsval. A "programknyvtr" kifejezs egyszeren egy olyan fjlt
jell, ami lefordtott trgykdot (s adatot) tartalmaz, amit ksbb egy
programmal ssze lehet szerkeszteni (link). A programknyvtrak lehetv
teszik, hogy az alkalmazs modulrisabb, gyorsabban jrafordthat s
knnyebben frissthet legyen. A programknyvtrakat hrom tpusba
sorolhatjuk: statikus programknyvtrak, megosztott programknyvtrak s
dinamikusan betlthet (DL) programknyvtrak.

Ez a lers elszr a statikus programknyvtrakkal foglalkozik, melyeket a
program futtatsa eltt kell az alkalmazshoz szerkeszteni. Ezt kveten
foglalkozik a megosztott (shared) programknyvtrakkal, amelyek a program
indulsakor tltdnek be, s tbb program kztt megoszthatak. Vgl pedig
a dinamikusan betlthet (DL) programknyvtrakrl lesz sz, amiket a
programvgrehajts alatt tlthetnk be. A DL programknyvtrak nem igazn
trnek el formtumban a msik kt programknyvtr-tpustl (mind statikus,
mind megosztott programknyvtrak lehetnek DL programknyvtrak), a
klnbsg abbl addik, hogyan hasznljk a programozk a DL
programknyvtrakat. A HOGYAN egy fejezetnyi pldval s egy fejezetnyi
hivatkozssal zrul.

Minden programoznak, aki programknyvtrakat fejleszt elvileg megosztott
programknyvtrakat kellene ksztenie azrt, hogy lehetv tegye a
felhasznlknak a programknyvtrak alkalmazstl fggetlen frisstst. A
dinamikusan betlthet (DL) programknyvtrak hasznosak, de kicsivel tbb
munkt ignyel a hasznlatuk, s sok programnak nincs szksge arra a
rugalmassgra amit nyjtanak. Ezzel szemben a statikus programknyvtrak
sokkal krlmnyesebb teszik a frisstst. Ezrt ritkn ajnlott a
hasznlatuk. Ezzel egytt mindegyik programknyvtr-tpusnak van elnye,
mely elnyket egy-egy fejezetben foglaljuk ssze a ksbbiekben. A
dinamikusan betlthet (DL) programknyvtrakat hasznl C++ fejlesztknek
a "C++ dlopen mini-HOGYAN" is ajnlott olvasmny.

Elg szerencstlen, hogy j nhnyan a dinamikusan szerkesztett (linked)
programknyvtrak (DLL-ek) kifejezst hasznljk a megosztott
programknyvtrakra. Msok ugyanezt a kifejezst brmely olyan
programknyvtrra hasznljk, mely dinamikusan betlthet. Megint msok a
DLL-t a programknyvtrakra hasznljk megktsek nlkl. Fggetlenl attl,
hogy te mit rtesz alatta, ez a HOGYAN a DLL-ekkel foglalkozik Linuxon.

A HOGYAN csak a ELF (Executable and Linking Format) formtum futtathat
fjlokkal s programknyvtrakkal foglalkozik. Ezt a formtumot hasznlja a
legtbb Linux terjeszts. A GNU gcc eszkzkszlet ettl eltr
formtumokat is kpes kezelni, pldul a legtbb Linux terjeszts mg mindig
hasznlja az elavult a.out formtumot. Ugyanakkor ez a formtum kvl esik
ennek a HOGYANnak a tmakrn.

Ha hordozhat alkalmazs szeretnl kszteni, akkor megfontoland a [38]GNU
libtool hasznlata. Ebben az esetben a programknyvtrakat ezzel az
eszkzzel kszted s telepted, a linuxos eszkzk kzvetlen hasznlata
helyett. A GNU libtool egy ltalnos programknyvtr-ksztst s teleptst
tmogat szkript-kszlet, ami konzisztens s hordozhat fellettel rejti el
a megosztott programknyvtrak hasznlatnak bonyolultsgt. Linuxon a GNU
libtool azokra az eszkzkre s egyezmnyekre pl kzvetlenl, melyeket ez
a HOGYAN trgyal. Szmtalan hordozhatsgot biztost illesztfellet
(wrapper) ltezik dinamikusan betlthet programknyvtrakhoz is. A GNU
libtool tartalmaz egy ilyen illesztfellet programknyvtrat "libltdl"
nven. Egy msik alternatva lehet a glib programknyvtr hasznlata (nem
sszekeverend a glibc-vel), ami hordozhat tmogatst nyjt a dinamikusan
betlthet modulokhoz. Tovbbi informcit a
[39]http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.
html honlapon tallsz. Mg egyszer: Linuxon ez a funkci az ebben a
HOGYANban lert mdszerekkel is megvalsthat. Ha jelenleg Linuxon
fejlesztesz vagy hibt keresel, akkor valsznleg az ebben a HOGYANban
tallhat informcikra lesz szksged.

A [40]http://www.dwheeler.com/program-library webhely a kzponti elrsi
helye a HOGYANnak (angol verzi), az elksztsben kzremkdtt a The
Linux Documentation Project ([41]http://www.tldp.org). A szerzi jogokat
David A. Wheeler birtokolja Copyright (C) 2000, a dokumentumra a General
Public License (GPL) rvnyes; tovbbi informcit az utols fejezetben
tallsz errl.
     _________________________________________________________________

1.1. Magyar fordts

A magyar fordtst [42]Szalai Ferenc Attila ksztette (2003.12.11). A
lektorlst [43]Daczi Lszl vgezte el (2004.03.01). A dokumentum
legfrissebb vltozata megtallhat a [44]Magyar Linux Dokumentcis Projekt
honlapjn.
     _________________________________________________________________

2. Statikus programknyvtrak

A statikus programknyvtrak kznsges trgykd-fjlok gyjtemnyei.
Megllapods szerint a statikus programknyvtrak ".a" kiterjesztssel
vgzdnek. Egy ilyen gyjtemny az ar (archiver) programmal kszthet. A
statikus programknyvtrakat ma mr nem hasznljk olyan gyakran, mint
rgebben, figyelembe vve a megosztott programknyvtrak elnyeit (lsd
lejjebb). Nha azonban, mg mindig ksztenek ilyeneket. Trtnelmileg k
jelentek meg elszr, s egyszerbb is elmagyarzni mkdsket.

A statikus programknyvtrak lehetv teszik a felhasznlknak, hogy
jrafordts nlkl szerkesszk ket a programokhoz, ezzel lervidtve a
fordtsi idt. Megjegyezzk, hogy a mai gyors fordtk mellett a
jrafordtsi id kevsb fontos szempont, gy ez ma mr nem olyan ers
rv, mint rgebben. A statikus programknyvtrak gyakran hasznosak azoknak a
fejlesztknek, akik lehetv akarjk tenni a programozk szmra, hogy
szerkesszk a programjukat a programknyvtrukhoz, de nem akarjk a
programozk rendelkezsre bocstani a programknyvtr forrst. (Ez
elnys lehet a programknyvtr forgalmazjnak, de nyilvnvalan htrnyos
annak a programoznak, aki azt hasznlni szeretn). Elmletileg a programhoz
csatolt statikus ELF programknyvtrban lv kd kiss gyorsabban (1-5%-al)
futhat, mint a megosztott vagy dinamikusan betlthet programknyvtrban
lv. Gyakorlatilag ez ritkn ad okot a statikus programknyvtrak
hasznlatra, az egyb zavar tnyezk miatt.

A statikus programknyvtr ksztshez, vagy a mr meglv program
knyvrhoz j trgykd-fjlok hozzadshoz az albbi utastst hasznljuk:

ar rcs my_library.a file1.o file2.o

   Ez az egyszer utasts hozzadja a file1.o s file2.o
   trgykd-fjlokat a my_library.a statikus programknyvtrhoz.
   Ltrehozza a my_library.a fjlt, ha az nem ltezett. Tovbbi
   informcikat a statikus programknyvtrak ksztsrl az ar(1)-ben
   tallsz.

   Ha elksztettl egy statikus programknyvtrat nyilvn hasznlni is
   akarod. gy hasznlhatod a statikus programknyvtrat, hogy hivatkozol
   r fordtsi s szerkesztsi folyamatnak abban a fzisban, amikor a
   program futtathat fjlja kszl. Ha gcc(1)-et hasznlsz a futtathat
   fjl ksztsre, akkor a -l opcival rhatod el hasznlni kvnt
   programknyvtrak programhoz szerkesztst. Tovbbi informcit az
   info:gcc-ben tallsz.

   Lgy vatos a paramterek sorrendjvel, ha gcc-t hasznlsz. Mivel a -l
   a szerkeszt (linker) kapcsolja, gy azt a fordtand fjl neve UTN
   tedd. Ez egy kicsit klnbzik a normlis kapcsolmegadsi
   szintaxistl. Ha a fjl el teszed a -l opcit, akkor a csatols
   tkletesen hibs lesz s misztikus hibkat eredmnyez.

   Hasznlhatod a linker programot ld(1) kzvetlenl is a -l s -L
   opcikkal, de a legtbb esetben jobb a gcc(1)-t hasznlni, mivel az
   ld(1) interfsze nagyobb valsznsggel vltozik, mint a gcc
   fordt.
     _________________________________________________________________

3. Megosztott programknyvtrak

Megosztott programknyvtrak olyan programknyvtrak, amiket a program
indulsakor tlt be. Ha a megosztott programknyvtrak megfelelen vannak
teleptve, az sszes program az indulsa utn automatikusan j megosztott
programknyvtrat hasznl. Ez ennl egy kicsit rugalmasabb s bonyolultabb
jelenleg, mert a linuxos megolds megengedi azt is, hogy:

     * frisstsd a programknyvtraidat s kzben tmogasd azokat a
       programokat is, amik a rgebbi vltozatait hasznljk azoknak a
       programknyvtraknak, amik visszafele nem kompatibilisek.
     * fellbrlj specifikus programknyvtrakat vagy fggvnyeket a
       programknyvtrban klnleges programok futtatsakor.
     * mindezt a programok futsa kzben tegyed, mikzben azok a mr
       ltez programknyvtrakat hasznljk.
     _________________________________________________________________

3.1. Konvencik

A fent lert tulajdonsgok megvalstshoz a megosztott
programknyvtraknak szmos konvencit s irnyelvet kvetnik kell. Fontos
megrteni a klnbsget a programknyvtrak nevei kztt, klnsen a
"so-nv" s a "valdi nv" kztt (s azok kapcsolatt). Azt is meg kell
rtened, hogy hova kell elhelyezni ezeket a programknyvtrakat a
fjlrendszerben.
     _________________________________________________________________

3.1.1. Megosztott programknyvtrak nevei

Minden megosztott programknyvtrnak van egy specilis neve, amit
"so-nv"-nek hvnak. Az so-nvnek van egy "lib" eltagja, ezt kveti a
programknyvtr neve, majd egy ".s tag majd egy pont, s a verziszm (egy
specilis kivtel az alacsony szint C programknyvtrak, amik nem
kezddnek "lib"-el). A verziszm akkor nvekedik, ha az interfsz
vltozik. A "teljes so-nv" tartalmazza eltagknt a knyvtr (directory)
nevt, amiben a programknyvtr tallhat. Egy mkd rendszeren a teljes
so-nv egyszeren egy szimbolikus hivatkozs a megosztott programknyvtr
valdi nevre.

Minden megosztott programknyvtrnak van "valdi neve" is, ami annak az
fjlnak a neve, ami a jelenlegi programknyvtr kdjt tartalmazza. A valdi
nv az so-nvhez ad egy pontot, a minor szmot, egy jabb pont-ot s a
kibocstsi szmot (release number). Az utols pont s a kibocstsi szm
opcionlis. A minor szm s a kibocstsi szm arra val, hogy tudd,
pontosan melyik vltozata van az adott programknyvtrnak teleptve.
Megjegyezzk, hogy ezek a szmok nem felttlenl egyeznek meg azzal, amilyen
verziszmmal a programknyvtr dokumentcijban hivatkoznak, habr az
megknnyten a dolgokat.

Van tovbb egy nv, amit a fordtsnl hasznlunk, amikor a
programknyvtrra hivatkozunk (ezt "csatolsi nv"-nek fogjuk hvni). Ez
egyszeren a so-nv verzi nlkl.

A megosztott programknyvtrak hasznlatnak kulcsa a neveik
sztvlasztsban rejlik. A programokban a szksges megosztott
programknyvtrak so-neveire van csak szksg. Ennek megfelelen, amikor
egy megosztott programknyvtrat ksztesz, mindssze egy programknyvtrat
ksztesz egy specilis fjlnven (rszletes verzi informcikkal). Amikor
telepted az j vltozatt a programknyvtrnak, akkor a megfelel
knyvtrak egyikbe kell elhelyezned s az ldconfig(8) programot kell
futtatnod. Az ldconfig megvizsglja a ltez fjlokat s elkszti a
so-neveket, mint szimbolikus hivatkozsokat a valdi nevekre, ezzel egytt
belltja az /etc/ld.so.cache gyorstr-fjlt is.

Az ldconfig nem lltja be a szerkesztsi neveket, ltalban ez megtrtnt
mr a programknyvtr teleptse sorn, a szerkesztsi nv egyszeren egy
szimbolikus hivatkozs a "legjabb" so-nvre vagy a legjabb valdi nvre.
Az tancsolnm legyen a csatolsi nv egy szimbolikus hivatkozs az
so-nvre, mivel a legtbb esetben a frisstett programknyvtrat szeretnd
automatikusan hasznlni, mikor csatolod azt a programodhoz. Megkrdeztem H.
J,. Lu-t, mirt nem lltja be automatikusan az ldconfig a szerkesztsi
neveket. A magyarzata alapveten az volt, hogy taln a programknyvtr
legutbbi verzijt szeretnd futtatni a kddal, de az is lehet, hogy egy
fejleszti vltozatra szeretnl hivatkozst egy rgi - taln inkompatibilis
- programknyvtr helyett. Ezrt az ldconfig nem ksrli meg kitallni, hogy
mit akarsz a programhoz csatolni, gy a teleptnek kell meghatrozni azt,
s mdostani a szimbolikus hivatkozst arra a programknyvtrra, amit a
szerkeszt hasznlni fog.

gy az /usr/lib/libreadline.so.3 egy teljes so-nv, amit az ldconfig
ksztett, pldul mint szimbolikus hivatkozst a
/usr/lib/libreadline.so.3.0 fjlra. Kellene lennie egy
/usr/lib/libreadline.so szerkesztsi nvnek is, ami egy szimbolikus
hivatkozs lehet a /usr/lib/libreadline.so.3 fjlra.
     _________________________________________________________________

3.1.2. Elhelyezs a fjlrendszerben

A megosztott programknyvtrakat el kell helyezni valahol a fjlrendszerben.
A legtbb nylt forrs szoftver a GNU szabvnyok (standards) kvetsre
trekszik. Tovbbi informcit az [45]info:standards#Directory_Variables
info dokumentumban tallhatsz. A GNU szabvnyok azt ajnljk, hogy
alaprtelmezsben minden programknyvtrat az /usr/local/lib knyvtrba
teleptsnk a forrskd kzzttelekor (s minden parancsnak az
/usr/local/bin knyvtrba kellene kerlnie). Ezek a szabvnyok konvencikat
is meghatroznak arra vonatkozlag, hogyan brljuk fell ezt az
alaprtelmezett belltst a teleptsi eljrs sorn.

A Filesystem Hierarchy Standard (FHS) meghatrozza mi hol legyen egy
terjesztsben (lsd: [46]http://www.pathname.com/fhs). Az FHS szerint a
legtbb programknyvtrat az /usr/lib knyvtrba kell telepteni, de azokat
amik az elindulshoz szksgesek a /lib knyvtrban kellene lennik, s azok
a knyvtrak, melyek nem rszei a rendszernek azokat kellene a
/usr/local/lib knyvtrba rakni.

Nincs igazn ellentmonds a kt dokumentum kztt. A GNU szabvnyok a
fejlesztknek, mg az FHS a terjesztst sszelltknak (akik szelektven
fellbrljk a forrs alaprtelmezett belltsait, rendszerint a rendszer
csomagkezeljvel) szl ajnlsok. Gyakorlatilag ez szpen mkdik: a
"legjabb" (valsznleg hibs!) forrst, amit letltesz, automatikusan a
"local" knyvtrba (/usr/local) telepti magt, azoknl a kdoknl, amik
"megrtek" a csomag kezelk magtl rthetdben fellbrljk az
alaprtelmezett belltsokat, s elhelyezik a kdot az alaprtelmezett
helyre a terjesztsben. Megjegyezzk, hogy ha a programknyvtrad meghv
olyan programokat, amik csak a programknyvtrak ltal hvhatak, akkor
ezeket a programokat a /usr/local/libexec (ami /usr/libexec a Linux
terjesztsekben) kell elhelyezni. A Red Hat alap rendszerek egy
sajtossga, hogy az /usr/local/lib knyvtr nincs az alaprtelmezett
programknyvtr-keressi tvonalban (lsd a megjegyzseket az
/etc/ld.so.conf fjlrl lejjebb). Egy msik szokvnyos programknyvtr-hely
az /usr/X11R6/lib, ahova az X-winodows rendszerrel kapcsolatos
programknyvtrakat szoks elhelyezni. Megjegyezzk, hogy a /lib/security a
PAM modulok ltal hasznlt hely, de ezek rendszerint DL programknyvtrak
(lsd lejjebb).
     _________________________________________________________________

3.2. Hogyan hasznljuk a programknyvtrakat?

GNU glibc alap rendszereken - ide tartozik az sszes Linux rendszer - egy
ELF binris futtathat fjl elindtsa automatikusan magval vonja a
programbetlt elindtst. Linux rendszereken ennek a betltnek a neve
/lib/ld-linux.so.X (ahol X a verzi szmot jelli). Ez a betlt keresi meg
s tlti be az sszes program ltal hasznlt megosztott programknyvtrat.

Azoknak az elrsi utaknak a listja, amiben a betlt a
programknyvtrakat keresi, az /etc/ld.so.conf fjlban tallhat. Tbb Red
Hat alap terjesztsben a /usr/local/lib nem tallhat meg ebben a fjlban.
Ezt n hibnak tekintem s az /usr/local/lib hozzadst az /etc/ld.so.conf
fjlhoz egy ltalnos "javtsnak" gondolom, ami minden Red Hat alap
rendszeren szksges lehet.

Ha fell akarsz brlni nhny eljrst egy programknyvtrban, de meg
akarod tartani az eredetit, akkor elhelyezheted a fellbrland
programknyvtrak nevt (.o fjlok) az /etc/ld.so.preload fjlban. Ezek az
"eltlttt" programknyvtrak elsbbsget lveznek a standard
programknyvtrakkal szemben. Ez az eltlt fjl ltalban tmenti
foltozsra szolgl, s a terjesztsek rendszerint nem tartalmaznak
ilyeneket.

Nem igazn hatkony ezeket az elrsi utakat megkeresni minden
programindtsakor. Ezrt egy gyorstraz mdszert alkalmazunk. Az
ldconfig(8) program alaprtelmezsben az /etc/ld.co.conf fjlt olvasva
belltja a megfelel szimbolikus hivatkozsokat a dinamikus hivatkozsok
knyvtraiban (dynamic link directories) (gy azok a konvencikat fogjk
kvetni), s egy gyorstr-fjlt kszt /etc/ld.so.cache nven. Ezt a
gyorstrat hasznlja aztn a tbbi program. Ez nagyon felgyorstja a
programknyvtrak elrst. A kvetkezmny az, hogy az ldconfig parancsot
minden esetben futtatni kell, ha j DLL-at adunk a rendszerhez vagy ha
eltvoltjuk azt, vagy mikor tlltjuk a DLL programknyvtrakat. Az
ldconfig futtats a leggyakoribb feladat, amit egy csomagkezelnek el kell
vgeznie, mikor programknyvtrat telept. Indulsnl a dinamikus betlt
az /etc/ld.so.cache fjlt hasznlja s utna tlti be a szksges
programknyvtrakat.

Megjegyezzk, hogy a FreeBSD teljesen ms fjlnevet hasznl ennek a
gyorstrnak. FreeBSD-ben az ELF gyorstr a /var/run/ld-elf.so.hints, mg az
a.out gyorstr a /var/run/ld.so.hints fjl. Az ldconfig(8) ezeket is
frissti, gy ez az elnevezsbeli klnbsg csak nhny egzotikus esetben
rdekes.
     _________________________________________________________________

3.3. Krnyezeti vltozk

Szmos krnyezeti vltozval szablyozhat az elbb bemutatott mkds.
Ezek a krnyezeti vltozk lehetv teszik, hogy beavatkozzunk a
programknyvtrak betltsnek s hasznlatnak menetbe.
     _________________________________________________________________

3.3.1. LD_LIBRARY_PATH

tmenetileg helyettesthetsz nhny programknyvtrat bizonyos programok
futtatsakor. Linuxon a LD_LIBRARY_PATH krnyezeti vltoz egy
kettsponttal elvlasztott listja azoknak az elrsi utaknak, ahol a
programknyvtrakat keresi, a szoksos helyek eltt. Ez hasznos
hibakeresskor, ha egy j vagy nem szokvnyos programknyvtrat hasznlunk
valamilyen specilis clbl. Az LD_PRELOAD krnyezeti vltoz egy
kettsponttal elvlasztott listja azoknak a megosztott
programknyvtraknak, amelyek fggvnyei felldefiniljk a standard
programknyvtrakt, mint ahogy azt az /etc/ld.so.preload teszi. Meg kell
emltennk, hogy a LD_LIBRARY_PATH hasznlhat majdnem minden Unix-szer
rendszeren, de nem mindegyiken. Pldul ez a funkci elrhet HP-UX-on, de
a krnyezeti vltoz neve SHLIB_PATH. AIX-on ezt a funkcit a LIBPATH nev
vltozval rhetjk el (ugyanezzel a szintaxissal, kettsponttal
elvlasztott lista).

LD_LIBRARY_PATH knyelmes fejlesztsnl vagy tesztelsnl, de szksgtelen
mdostania egy norml felhasznlnak vagy akr egy teleptsi eljrsnak
norml esetben. A mirtekrl a "Why LD_LIBRARY_PATH is Bad" cm rsban,
a [47]http://www.visi.com/~barr/ldpath.html honlapon olvashatsz. Ezek
ellenre hasznlhat fejlesztskor vagy tesztelskor, vagy ha egy problma
behatrolsa nem megy mskppen. Ha nem akarod belltani a LD_LIBRARY_PATH
krnyezeti vltozt, akkor Linuxon kzvetlenl futtathatod a
programbetltt, megfelel argumentumokkal. Az albbi pldban a PATH-ot
fogja hasznlni az LD_LIBRARY_PATH krnyezeti vltoz tartalma helyett, gy
futtatja a megadott fjlt.

  /lib/ld-linux.so.2 --library-path PATH EXECUTABLE

Az ld-linux.so argumentum nlkl futtatva tovbbi informcikat add arrl,
hogyan hasznlhatod, de mg egyszer hangslyozom, hogy norml krlmnyek
kztt ne hasznld ezt, kizrlag hibakeressre.
     _________________________________________________________________

3.3.2. LD_DEBUG

Msik hasznos krnyezeti vltoz az LD_DEBUG, a GNU C betltben. Ez a
vltoz arra knyszerti a dl* fggvnyeket, hogy bsges informcit
adjanak arrl, hogy mit csinlnak. Pldul:

  export LD_DEBUG=files
  command_to_run

megjelenti a fjlok s programknyvtrak feldolgozst, mikor a
programknyvtrakat kezeli. Megjelenti, milyen fggsgeket tallt a
rendszer, s milyen so-k lesznek betltve, milyen sorrendben. Az LD_DEBUG-t
"bindings"-re lltva informcikat kapunk a szimblum ktsrl. A "libs"
bellts a programknyvtrak keressi tvonalt mutatja. A "versions"
bellts pedig a verzi fggsgeket jelenti meg.

   Az LD_DEBUG-ot "help"-re lltsa utn, ha megprblunk futtatni egy
   programot, a rendszer megjelenti a lehetsges belltsokat (a
   programot nem futtatja le). Mg egyszer megjegyezzk, hogy az
   LD_DEBUG-ot nem norml hasznlatra terveztk, de nagyon hasznos lehet
   hibakeressnl s tesztelsnl.
     _________________________________________________________________

3.3.3. Tovbbi krnyezeti vltozk

Szmos ms krnyezeti vltoz is van, ami a betltsi eljrst szablyozza.
Ezek LD_ vagy RTLD_ eltagokkal kezddnek. A legtbb alacsony szint
hibakeresst tesz lehetv a betltsi eljrsban, vagy specilis
tulajdonsgok megvalstst teszik lehetv. A legtbb nem tl jl
dokumentlt. Ha szksged van rjuk legjobb, ha elolvasod a betlt
forrskdjt, ha tbbet akarsz megtudni ezekrl a krnyezeti vltozkrl.

A felhasznli beavatkozs engedlyezse a dinamikusan csatolt
programknyvtrak betltsnl katasztroflis eredmnyre vezethet,
setuid/setgid-es programok esetn. Ezrt a GNU betltben (ami betlti a
program tbbi rszt annak indulsakor), ha a program setuid vagy setgid
belltsokkal rendelkezik, akkor az eddig emltett s a tbbi hasonl
krnyezeti vltoz vagy figyelmen kvl marad, vagy hatsa ersen
korltozva lesz. Ha az uid s az euid, vagy ha a gid s a egid klnbzik, a
betlt felttelezi, hogy a program setuid vagy setgid-es (vagy annak
gyermeke), ezrt jelentsen cskkenti a csatols kontrolllsnak
lehetsgt krnyezeti vltozkkal. Ha a GNU glibc programknyvtr
forrskdjt olvasod, lthatod ezt, klnsen az elf/rtlf.c s a
sysdeps/generic/dl-sysdep.c fjlokat olvasva. Ez azt jelenti, ha elred,
hogy a uid s a euid, valamit a gid s egid megegyezzenek ezek a vltozk
kifejtik teljes hatsukat, mikor a programot futtatod. Ms Unix-szer
rendszerek hasonl okbl kifolylag, de mshogy kezelik ezt a problmt: a
setuid s setgid-es programot indokolatlanul nem befolysolhatjuk krnyezeti
vltozkkal.
     _________________________________________________________________

3.4. Megosztott programknyvtrak ksztse

Megosztott programknyvtrat kszteni knny. Elszr egy trgykd-fjlt
kell ksztennk, amit a megosztott programknyvtrba fogunk pakolni, a gcc
-fPIC vagy -fpic kapcsolinak segtsgvel. A -fPIC s -fpic opcik
engedlyezik a "pozci fggetlen kd" (position independent code)
generlst, ami szksges a megosztott programknyvtrak ksztshez (a
klnbsgeket lsd albb). Az so-nevet a -Wl kapcsolval adhatod meg a
gcc-nek. A -Wl opci a szerkesztnek (linker) szl (ebben az esetben a
-soname linker opci) - a vesszk a -Wl utn nem helyesrsi hibk, s nem
szabad szkzket tenni kzjk. A megosztott programknyvtr ksztshez
az albbi formtumot hasznld:

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

   me egy plda, ami kt trgykd-fjlt kszt (a.o s b.o) aztn
   ezekbl egy megosztott programknyvtrat. Megjegyezzk, hogy ez a
   fordts (compile) tartalmazza a hibakeressi (debug) informcikat s
   a figyelmeztetsek (warnings) generlst is, amik nem felttlenl
   szksgesek a megosztott programknyvtrak ksztshez. A fordts
   trgykd-fjlokat llt el (-c hasznlata), s tartalmazza a
   szksges -fPIC kapcsolt:
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 nhny j tancs:

     * Ne hasznld a strip parancsot a keletkezett programknyvtrra.
       Tovbb ne hasznld a -fomit-frame-pointer fordtsi kapcsolt,
       hacsak nincs r igazn szksged. Az elkszlt programknyvtr
       mkdni fog ezekkel is, de a hibakeresket hasznlhatatlann
       teszik.
     * Hasznld a -fPIC vagy a -fpic kapcsolt a kd generlskor. Mind a
       -fPIC, mind a -fpic kapcsolkkal ksztett kd clplatform-fgg.
       A -fPIC vlaszts mindig mkdik, de nagyobb kdot generlhat,
       mint a -fpic (knny megjegyezni: PIC nagy bets, teht nagyobb
       kdot generl) A -fpic opci hasznlatval ltalban kisebb s
       gyorsabb kdot kapunk, de lesznek platformfgg korltozsok, s
       szmos globlisan lthat szimblum. A szerkeszt (linker) jelzi,
       hogy az gy ltrehozott trgykd alkalmas-e megosztott
       programknyvtr ksztsre. Minden esetben, mikor bizonytalan
       vagy -fPIC kapcsolt vlaszd, mert az mindig mkdik.
     * Nhny esetben a "-Wl,-export-dynamic" gcc kapcsolk is
       szksgesek lehetnek a trgykd-fjl ltrehozshoz. Normlis
       esetben a dinamikus szimblum tblzat csak azokat a szimblumokat
       tartalmazza, amiket a dinamikus trgykd-fjl hasznl. Ez a
       kapcsol (mikor ELF tpus fjlt ksztnk) hozzadja az sszes
       szimblumot a dinamikus szimblum tblzathoz (lsd ld(1) tbb
       informcirt). Ezt a kapcsolt kell hasznlnod, amikor vannak
       "visszafel fggsgek" (reverse dependences), gy mint amikor
       egy DL programknyvtrban fel ne oldott szimblumok vannak, amiket
       a hagyomny szerint definilni kell abban a programban, amelyik be
       szeretn tlteni ezeket a programknyvtrakat. A "visszafel
       fggsg" mkdshez a fprogramnak dinamikusan elrhetv kell
       tennie ezeket a szimblumokat. Megjegyezzk, hogy hasznlhatod a
       "-rdynamic" kapcsolt a "-Wl,export-dynamic" helyett, ha csak
       Linux rendszeren dolgozol, de az ELF dokumentcija szerint az
       "-rdynamic" kapcsol nem mindig mkdik gcc-nl nem Linux-alap
       rendszereken.

   Fejleszts kzben az egyik tipikus problma annak a programknyvtrnak
   a mdostsa, amit ms programok is hasznlnak -- s nem szeretnd,
   hogy a tbbi program is a "fejlesztsi" programknyvtrat hasznlja,
   csak egy kiszemelt alkalmazst szeretnl tesztelni vele. Az ld "rpath"
   szerkesztsi (link) opcijt kell hasznlnod ebben az esetben, ami
   szerkesztsi idben meghatrozza a futsidej programknyvtr
   (runtime library) keressi tvonalt egy adott programra. A gcc-t az
   rpath opcival az albbi mdon hasznlhatod:
    -Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH)

   Ha ezt az opcit hasznlod amikor elkszted (build) a programknyvtr
   kliens programjt, akkor nem kell azzal vacakolnod, hogy a
   LD_LIBRARY_PATH-al elkerld a sszetkzseket vagy, hogy ms
   mdszerekkel elrejtsd a programknyvtrat.
     _________________________________________________________________

3.5. Megosztott programknyvtrak teleptse s hasznlata

Ha mr ksztettl megosztott programknyvtrat, nyilvn hasznlni is
akarod. Az egyik lehetsg, hogy egyszeren a szabvnyos knyvtrak
egyikbe msolod a programknyvtrat (pl. /usr/lib) s lefuttatod a
ldconfig(8)-ot.

Elszr is ksztened kell egy megosztott programknyvtrat valahol. Aztn
be kell lltanod a szksges szimbolikus hivatkozsokat (symbolic links),
klnsen a so-nvrl a valdi nvre (akrcsak a verzimentes so-nvrl
mutatt - ami a so-nv ami ".s-val vgzdik - azoknak a felhasznlknak,
akik nem hatroznak meg verzit egyltaln). Az egyszerbb megolds, hogy
az albbi parancsot futtatod:

 ldconfig -n directory_with_shared_libraries

   Vgl, amikor fordtod a programodat, meg kell mondanod a
   szerkesztnek azokat a statikus s megosztott programknyvtrakat,
   amiket hasznlni akarsz. Erre hasznld a -l s -L kapcsolkat.

   Ha nem tudod, vagy nem akarod telepteni a programknyvtradat egy
   standard helyre (pldul nincs jogod mdostani az /usr/lib
   knyvtrat), akkor ms megoldst kell vlasztanod. Ebben az esetben
   teleptened kell a programknyvtrat valahova, aztn elg informcit
   kell adnod a programodnak, hogy megtallja a programknyvtrat.
   Tbbfle md is ltezik erre. Hasznlhatod a gcc -L kapcsoljt
   egyszerbb esetekben. Hasznlhatod a "rpath"-os megoldst (lsd
   feljebb), klnsen, ha csak egy specilis program hasznlja a
   programknyvtrat, ami a "nem-standard" helyen van. Hasznlhatsz
   krnyezeti vltozkat is, hogy kzben tartsd a dolgokat. Az
   LD_LIBRARY_PATH krnyezeti vltoz hasznlhatod, ami egy
   kettsponttal elvlasztott listja azoknak az elrsi utaknak, ahol a
   megosztott programknyvtrakat keressk, mieltt a szoksos helyeken
   prblkoznnk. Ha bash-t hasznlsz indthatod a my_program-ot gy:
   LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH  my_program

   Ha csak nhny kivlasztott fggvnyt akarsz mdostani, akkor
   megteheted, hogy ksztesz egy mdost trgykd-fjlt, s belltod a
   LD_PRELOAD krnyezeti vltozt. A fggvnyek ebben a trgykdban csak
   azokat a fggvnyeket fogjk fellrni, amik a programknyvtrban
   szerepelnek (a tbbit nem vltoztatja meg).

   Rendszerint nyugodtan frisstheted a programknyvtrakat, ha API
   vltozs volt a programknyvtr ksztje felttelezheten
   megvltoztatta a so-nevet. Ezrt lehet tbb programknyvtr egyszerre
   egy rendszeren, a megfelel lesz kivlasztva mindegyik programhoz. Ha
   a program mgis sszeomlik, a programknyvtr frisstsnek hatsra,
   rveheted, hogy hasznlja a rgebbi programknyvtr-verzit. Ehhez
   msold a rgi programknyvtrat vissza a rendszerre valahova.
   Vltoztasd meg a program nevt (legyen a rgi nv ".orig"
   kiterjesztssel), majd kszts egy kis indt-szkriptet, ami
   visszalltja a rgi programknyvtrat a programnak. A rgi
   programknyvtrat elhelyezheted egy sajt specilis helyre, ha akarod,
   hasznlhatod a szmozsi konvencit, hogy tbb verzi is lehessen
   ugyanabban a knyvtrban. me egy minta indt-szkript:
  #!/bin/sh
  export LD_LIBRARY_PATH=/usr/local/my_lib:$LD_LIBRARY_PATH
  exec /usr/bin/my_program.orig $*

   Krlek ne hasznld ezt, amikor a sajt programodat kszted. Prblj
   meggyzdni arrl, hogy a programknyvtraid vagy visszamenlegesen
   kompatibilisek, vagy nvelted a verzi szmot a so-nvben minden
   esetben, ha nem kompatibilis vltozst vgeztl. Ez csak egy
   vszmegolds a legrosszabb esetekre.

   Egy program ltal hasznlt megosztott programknyvtrak listjt az
   ldd(1) programmal kaphatod meg. Teht pldul, ha az ls program ltal
   hasznlt megosztott programknyvtrakat szeretnd ltni, rd a
   kvetkezt:
     ldd /bin/ls

   Megkapod azoknak a so-nevek listjt, amiktl a program fgg, a
   knyvtrral (directory) egytt, amiben azok a nevek feloldhatak.
   Gyakorlatilag minden esetben legalbb kt fggsged lesz:

     * /lib/ld-linux.so.N (ahol N 1 vagy tbb, rendszerint legalbb 2).
       Ez a programknyvtr ami betlti az sszes tbbit.
     * libc.so.N (ahol N 6 vagy tbb). Ez a C programknyvtr. Minden ms
       nyelv is igyekszik a C programknyvtrat hasznlni (ahelyett, hogy
       sajtot valstana meg), gy a legtbb program legalbb ezt az
       egyet hasznlja.

   Vigyzat: ne futtasd az ldd-t olyan programra, amiben nem bzol. Ahogy
   az vilgosan le van rva az ldd(1) kziknyvben, az ldd gy mkdik
   (a legtbb esetben), hogy bellt egy specilis krnyezeti vltozt
   (ELF trgykdok esetn az LD_TRACE_LOADED_OBJECTS-et) s futtatja a
   programot. Lehetsges egy megbzhatatlan program szmra, hogy rvegye
   az ldd felhasznlt mestersges kd futtatsra (ahelyett, hogy
   egyszeren megmutatn az ldd informcit). Teht a biztonsg kedvrt
   ne hasznld az ldd-t olyan programra, amiben nem bzol meg.
     _________________________________________________________________

3.6. Inkompatibilis programknyvtrak

Abban az esetben, ha egy programknyvtr j vltozata binrisan
inkompatibilis a rgivel, akkor a so-nevet meg kell vltoztatni. C-ben ngy
alapvet oka lehet annak, hogy egy programknyvtr inkompatibiliss vlik:

    1. A fggvny viselkedse megvltozik, nem egyezik meg az eredeti
       specifikcival.
    2. Nyilvnos adatelemek megvltoztak (kivtel: hozzadott opcionlis
       elemek a struktrk vgn nem okoznak problmt, ha ezeket a
       struktrkat csak a programknyvtr foglalja le)
    3. Nyilvnos fggvnyt eltvoltottak.
    4. A nyilvnos fggvny interfsze megvltozott.

   Ha ezeket el tudod kerlni, akkor a programknyvtraid binrisan
   kompatibilisek lesznek. Ms szval az alkalmazs binris interfsze
   (Application Binary Interface - ABI) kompatibilis maradhat, ha a fenti
   tpus vltoztatsokat elkerld. Pldul, hozz ltre j fggvnyeket,
   de ne trld a rgieket. Hozzadhatsz j elemeket a struktrkhoz, de
   csak akkor, ha meggyzdtl rla, hogy a rgi programok nem lesznek
   rzkenyek erre a vltozsra. Csak a struktra vgre adj j elemeket,
   s csak a programknyvtr (s nem az alkalmazs) ltal elfoglalt
   struktrkban teheted ezt meg. Az j elemek legyenek opcionlisak
   (vagy a programknyvtr tltse ki ket) stb. Figyelem: valsznleg
   nem tudod kiterjeszteni a struktridat, ha a felhasznlk tmbkben
   hasznljk azokat.

   C++ (illetve egyb fordtsi idben hasznlatos sablonokat (template)
   vagy "compiled dispatched" eljrsokat tmogat nyelvek) esetn a
   helyzet kicsit trkksebb. A fenti megktseket mind figyelembe kell
   venni, s meg sok minden mst is. Ennek oka, hogy nhny informci
   rejtve (under the covers) kerlt megvalstsra a lefordtott kdban.
   Ennek eredmnye nem nyilvnval, ha nem tudod, hogy tipikusan, hogy
   szoktk a C++-t megvalstani. Szigoran vve ezek nem "j" dolgok,
   csak arrl van sz, hogy C++ hasznlhat adatstruktrkat gy, hogy az
   a meglepets erejvel hathat. Az albbi egy - a [48]Troll Tech's
   Technical FAQ alapjn sszelltott (feltehetleg hinyos) listja
   azoknak a dolgoknak, amit nem tehetsz meg C++-ban, ha meg akarod
   tartani a kompatibilitst.

    1. virtulis fggvnyek jra megvalstsnak hozzadsa, (hacsak nem
       vagy benne biztos, hogy a rgi programok az eredeti megvalstst
       fogjk hasznlni). Mert a fordt mr fordtsi idben (nem
       csatolsi (link) idben) kirtkeli a
       SuperClass::virtualFunction() fggvnyhvst.
    2. virtulis tagfggvny hozzadsa vagy trlse, mert ez
       megvltoztathatja a minden alosztly vtbl-jnek mrett s
       szerkezett.
    3. brmilyen olyan adattag tpusnak megvltoztatsa vagy trlse,
       amit inline tagfggvnyek rnek el.
    4. osztlyhierarchia megvltoztatsa, kivve az j levelek
       hozzadst.
    5. privt adattag hozzadsa vagy elvtele, mert ez megvltoztatja a
       mrett s szerkezett minden alosztlynak.
    6. public vagy protected tagsgi fggvnyek eltvoltsa, hacsak nem
       inline tpusak.
    7. public vagy protected tagfggvny inline tpusv tenni.
    8. mdostani a inline tpus fggvnyek mkdst, kivve ha rgi
       vltozat tovbbra is mkdik.
    9. a tagsgi fggvnyek hozzfrsi jognak (public, protected vagy
       private) megvltoztatsa egy hordozhat programban, mert nhny
       fordt hozzadja a hozzfrsi jogot a fggvnynvhez.

   Ez a hossz lista is jl mutatja, hogy a C++ programknyvtr
   fejlesztknek bizonyos esetekben sokkal jobban meg kell terveznik a
   dolgokat, hogy megtartsk a binris kompatibilitst. Szerencsre
   Unix-szer rendszereken (a Linuxot is belertve) egy
   programknyvtrad tbb verzija lehet egyszerre betltve. gy amg van
   elg lemezterlet, a felhasznlk futtathatnak "rgi" programokat,
   amik rgi programknyvtrakat hasznlnak.
     _________________________________________________________________

4. Dinamikusan betlthet (Dynamically Loaded; DL) programknyvtrak

Dinamikusan betlthet (DL) programknyvtrak olyan programknyvtrak, amik
nem a program indulsakor tltdnek be. Klnsen hasznos modulok s
plug-in-ek megvalstsra, mivel lehetv teszi, hogy csak akkor tltsk
be ezeket, ha szksges. Pldul a Betlthet Hitelest Modul (Pluggable
Authentication Modules; PAM) rendszer DL programknyvtrakat hasznl, gy
lehetv teszi a rendszergazdknak, hogy belltsk s tlltsk az
hitelest/azonost eljrsokat. A dinamikusan betlthet
programknyvtrak jl hasznlhatak tovbb olyan rtelmezk
megvalstsra, amik alkalmanknt lefordtanak kdokat gpi kdra s a
lefordtott hatkony vltozatokat hasznljk, mindezt lells nlkl.
Pldul ez az eljrs hasznlhat just-in-time fordtk vagy multi-user
dungeon (MUD) megvalstsra.

Linuxon a DL programknyvtrak jelenleg formailag semmilyen specilis
tulajdonsggal nem rendelkeznek. Standard trgykdknt vagy megosztott
programknyvtrknt kszlnek, mint ahogy azt feljebb mr bemutattuk. A f
klnbsg, hogy ezek a programknyvtrak nem tltdnek be automatikusan a
program csatolsa vagy elindtsa sorn. Ehelyett van egy API, aminek
segtsgvel megnyithatjuk a programknyvtrat, szimblumokat kereshetnk
benne, javthatjuk a hibkat s bezrhatjuk a programknyvtrat. C
felhasznloknak a <dlfcn.h> header fjlt kell beszerkeszteni (include) ennek
az API-nak a hasznlathoz.

Az interfsz hasznlata Linuxon alapveten ugyanolyan mint Solaris-on, amit
"dlopen()" API-nak fogok hvni. Ugyanakkor ezt az interfszt nem tmogatja
minden platform. HP-UX egy msik shl_load() mechanizmust hasznl s a
Windows platform is egy teljesen ms DLL interfszt hasznl. Ha a clod a
szleskr hordozhatsg, akkor valsznleg valamilyen kztes
programknyvtrat kell hasznlnod, ami elrejti a klnbsgeket a platformok
kztt. Egy megolds lehet a glib programknyvtr, ami tmogatja a modulok
dinamikus betltst. Ez az platformok dinamikus betlt rutinjait
hasznlja ahhoz, hogy egy hordozhat interfszt valstson meg ezekhez a
fggvnyekhez. Tbbet tudhatsz meg a glib-rl a
[49]http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.
html honlapon. Mivel a glib interfsz jl dokumentlt nem rszletezem itt.
Egy msik lehetsg a libltdl hasznlata, ami rsze a [50]GNU libtool-nak.
Ha tbbet akarsz ennl, akkor vess egy pillantst a CORBA Object Request
Broker (ORB)-re. Ha mg mindig rdekel, hogyan hasznlhatod kzvetlenl a
Linux s Solaris interfszeket, akkor olvass tovbb.

Azok a fejlesztk aki C++-t s dinamikusan betlthet (DL)
programknyvtrakat akarnak hasznlni elolvashatjk a "C++ dlopen
mini-HOGYANt".
     _________________________________________________________________

4.1. dlopen()

A dlopen(3) fggvny megnyitja a programknyvtrat s elkszti
hasznlatra. C prototpusa az albbi:

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

Ha filename "/"-el kezddik (pldul egy abszolt elrsi t), dlopen() gy
fogja hasznlni ezt (nem fogja megkeresi a programknyvtrat). Egyb
esetekben a dlopen() az albbi sorrendben keresi a programknyvtrakat:

    1. Knyvtrak kettsponttal elvlasztott listja a felhasznl
       LD_LIBRARY_PATH krnyezeti vltozjban.
    2. Az /etc/ld.so.cache fjlban tallhat programknyvtrak
       listjban, amit az /etc/ld.so.conf-bl generltunk.
    3. /lib, aztn /usr/lib. Megjegyezzk, hogy ez pont a fordtottja a
       rgi a.out betlt viselkedsnek. A rgi a.out betlt elszr
       az /usr/lib knyvtrban keresett aztn a /lib knyvtrban (lsd
       ld.so(8) man oldal). Normlis krlmnyek kztt ez nem szmt, a
       programknyvtrnak az egyik vagy a msik knyvtrban kellene
       lennie (sohasem mindkettben), mivel azonos nvvel rendelkez
       klnbz programknyvtrak katasztrft okoznak.

   A dlopen()-ben a flag rtke RTLD_LAZY "akkor oldja fel a nem
   definilt szimblumokat, amint egy kd a dinamikus programknyvtrbl
   futtatsra kerl", vagy RTLD_NOW "felold minden nem definilt
   szimblumot, mieltt a dlopen() visszatr s hibt ad vissza, ha ez
   sikertelen volt". RTLD_GLOBAL opcionlisan vagy kapcsolatban
   hasznlhat brmelyikkel a flag-ban, ami azt jelenti, hogy a
   programknyvtrban definilt kls (external) szimblumok elrhetek
   lesznek a tbbi betlttt programknyvtrban is. Hibakeress kzben
   valsznleg az RTLD_NOW-t akarod majd hasznlni. Az RTLD_LAZY
   knnyen misztikus hibkat okozhat, ha feloldhatatlan referenciid
   vannak (unresolved references). Az RTLD_NOW esetn kicsit tovbb tart
   a programknyvtr betltse (de felgyorstja a keresst ksbb). Ha
   ez felhasznli interfsz problmt okozna, akkor RTLD_LAZY-re
   vlthatsz.

   Ha a programknyvtrak fggnek egymstl (pl.: X fgg Y-tl), akkor
   elszr a fggsgeket kell betltened (a pldban Y-t s aztn
   X-et).

   A dlopen() visszatrsi rtke egy "handle", amire gy tekinthetsz,
   mint egy opaque rtk, amit ms DL programknyvtrak hasznlhatnak. A
   dlopen() NULL-al fog visszatrni, ha a betlts sikertelen volt. Ezt
   ellenrizned is kell. Ha ugyanazt a programknyvtrat tbbszr tltd
   be dlopen()-el, az ugyanazt az fjlkezelt (handle) fogja visszaadni.

   Ha a programknyvtr tartalmaz egy _init nev public eljrst, akkor
   az abban lv kd lefut, mieltt a dlopen visszatr. Ezt a sajt
   program inicializcis eljrsnak hasznlhatod. Ugyanakkor a
   programknyvtraknak nem ktelez _init s _fini nev eljrsokat
   tartalmazniuk. Ez a mechanizmus elavult s nem kvnatos mkdst
   eredmnyezhet. Helyette a programknyvtraknak
   __attribute__((constructor)) s __attribute__((destructor)) fggvny
   attribtumokkal megjellt eljrsokat kellene hasznlniuk (feltve,
   hogy gcc-t hasznlsz). Tovbbi rszleteket a [51]"Programknyvtr
   konstruktor s destruktor fggvnyek" fejezetben olvashatsz errl.
     _________________________________________________________________

4.2. dlerror()

Hibkat a dlerror() fggvnyhvssal lehet kezelni. Ez visszatr az utols
dlopen(), dlsym() vagy dlclose() fggvnyhvs okozta hibt ler
karaktersorozattal. Kellemetlen, hogy a dlerror() meghvsa utn a tbbi
dlerror() fggvnyhvs NULL-al fog visszatrni mindaddig, amg egy msik
hiba nem keletkezik.
     _________________________________________________________________

4.3. dlsym()

Nincs rtelme betlteni egy DL programknyvtrat, ha nem tudod hasznlni. A
DL programknyvtr hasznlatnak alaprutinja a dlsym(3). Ez szimblumokat
keres a mr megnyitott programknyvtrakban. A fggvnydefinci gy nz ki:

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

A handle a dlopen ltal visszaadott rtk, a symbol egy NIL-el vgzd
karaktersorozat. Az a j, ha a dlsym eredmnyt nem trolod void* mutatban,
ellenkez esetben minden alkalommal ki kell osztanod (cast). (s kevs
informcit adsz azoknak az embereknek, akik megprbljk megrteni a
programodat)

   A dlsym() NULL-al tr vissza, ha a szimblumot nem tallta. Ha elre
   tudod, hogy a szimblum rtke soha nem NULL vagy zero, akkor ez
   rendben van, de potencilis veszlyforrs minden ms esetben. Ugyanis,
   ha kapsz egy NULL-t nem tudod eldnteni, hogy a szimblumot nem
   tallta a dlsym, vagy az rtke ppen NULL. A szoksos megolds
   ilyenkor, hogy elszr meghvod a dlerror()-t (azrt, hogy eltntess,
   minden hibt ami ltezik), aztn a dlsym()-et hvod a szimblum
   keressre, vgl jra a dlerror()-t, hogy lsd trtnt-e hiba. A
   kdrszlet valahogy gy nzhet 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() prja a dlclose(), ami bezrja a DL programknyvtrat. A DL
programknyvtr kapcsolatszmllkat (link counts) hoz ltre a dinamikus
fjlkezelkhz, gy a dinamikus programknyvtr mindaddig nem lesz
felszabadtva, amg a dlclose-t nem hvtk meg annyiszor, ahnyszor a
dlopen-t. gy nem okoz problmt, ha ugyanaz a program ugyanazt a
programknyvtrat tbbszr tlti be. Ha a programknyvtr valban
felszabadul a rgi programknyvtrak esetn a _fini fggvnye meghvdik (ha
ltezik). A _fini mr egy elavult mechanizmus s nem ajnlatos a hasznlata.
Helyette a programknyvtraknak az __attribute__((constructor)) s
__attribute__((destructor)) fggvnyattribtumukkal elltott eljrsit kell
hasznlni. Tovbbi rszleteket a [52]"Programknyvtr konstruktor s
destruktor fggvnyek" fejezetben olvashatsz errl. Megjegyezzk, hogy a
dlclose() 0-val tr vissza siker, s nem nullval hiba esetn. Nhny Linux
kziknyv oldal nem tesz emltst errl.
     _________________________________________________________________

4.5. DL programknyvtr plda

me egy plda a dlopen(3) kziknyvbl. Ez a plda betlti a math
programknyvtrat s kirja a 2.0 koszinuszt. Ellenrzi a hibkat, minden
lpsnl (ami melegen ajnlott):

    #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" llomnyban van, akkor az albbi paranccsal
   fordthatod le:
       gcc -o foo foo.c -ldl
     _________________________________________________________________

5. Egyb

5.1. nm utasts

Az nm(1) utasts megmutatja milyen szimblumok tallhatak egy adott
programknyvtrban. Mind statikus, mind megosztott programknyvtrakra
mkdik. Egy adott programknyvtrra az nm(1) a szimblumok neveit, s
minden szimblum tpust s rtkt kpes megmutatni. Azt is kpes
meghatrozni, hogy a forrskdban hol volt a szimblum definilva (fjlnv
s sor), ha ezt az informcit tartalmazza a programknyvtr (lsd a -l
kapcsolt).

A szimblum tpusok kicsit tbb magyarzatot ignyelnek. A tpust egy
karakter jelzi. A kisbet azt jelenti, hogy a szimblum loklis, mg a
nagybet azt, hogy globlis (kls). A tipikus szimblum tpusok a
kvetkezk: T (norml definci a kd rszben), D (inicializlt adat
szekci), B (nem inicializlt adat szekci), U (nem definilt; a szimblumot
hasznlja a programknyvtr de nincs definilva abban), s W (waek; ha ms
programknyvtr szintn definilja ezt a szimblumot, s az a definci
elrejti azt).

Ha tudod a fggvny nevt, de nem emlkszel, hogy melyik programknyvtrban
van definilva, akkor a nm "- kapcsoljt (ami minden sor el odarakja az
fjlnevet) hasznlhatod a grep-el egytt, hogy megtalld a programknyvtr
nevt. Bourne hjban kereshetsz minden programknyvtrban a /lib, /usr/lib,
/usr/local/lib s azok alknyvtraiban a "cos"-ra az albbiak szerint:

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

   Sokkal tbb informcit tallhat az nm-rl a "inf dokumentumban
   ([53]info:binutils#nm).
     _________________________________________________________________

5.2. Programknyvtr konstruktor s destruktor fggvnyek

A programknyvtrak megvalsthatnak nyilvnos inicializcis s cleanup
fggvnyeket, a gcc __attribute__((constructor)) s
__attribute__((destructor)) fggvny attribtumait hasznlva. Tovbbi
informcit a gcc info oldalain tallsz errl. A konstruktor eljrsok a
dlopen visszatrse eltt (vagy a main() eltt, ha a programknyvtr
betltsi idben kerl megnyitsra) hvdnak meg. A destruktor eljrsok a
dlclose visszatrse eltt (vagy a exit() vagy a main() befejezsekor, ha a
programknyvtr betltsi idben kerlt megnyitsra) hvdnak meg. A C
prototpusa ezeknek a fggvnyeknek a kvetkez:

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

   A megosztott programknyvtrakat tilos a gcc "-nostartfiles" vagy
   "-nostdlib" kapcsolival fordtani. Ha ezeket hasznljuk a
   konstruktor/destruktor eljrsok nem fognak lefutni (hacsak valami
   specilis nem trtnik).
     _________________________________________________________________

5.2.1. Specilis fggvnyek, _init s _fini (ELAVULT/VESZLYES)

Trtnelmileg ltezik kt specilis fggvny a _init s a _fini, amik
lehetv teszik a konstruktorok s a destruktor vezrlst. Ugyanakkor ezek
elavultak s hasznlatuk megjsolhatatlan viselkedst eredmnyezhet. A
programknyvtraidban szksgtelen ezeket hasznlnod. Helyettk a fenti
fggvny argumentumokkal elltott konstruktor s destruktor fggvnyeket
hasznld.

Ha rgi rendszeren kell dolgoznod, vagy olyan kddal ami hasznlja a _init
vagy a _fini fggvnyeket, akkor itt tallhat a mkdsi lersuk. Kt
specilis fggvnyt definiltak a modulok inicializlsra s a befejezsre:
_init s a _fini. Ha a programknyvtrban nyilvnos "_init" fggvny van
definilva, akkor az meghvdik, amikor a programknyvtrat elszr
megnyitjuk (dlopen()-el vagy egyszeren megosztott programknyvtrknt). C
programban ez egyszeren azt jelenti, hogy definilsz egy fggvnyt _init
nvvel. Ltezik egy _fini nev fggvny, ami meghvdik mindannyiszor, ha a
program befejezi a programknyvtr hasznlatt. (dlclose() meghvsval,
amikor az a referencia szmlt 0-ra lltja vagy a program normlis
kilpsekor). A C prototpusok:

  void _init(void);
  void _fini(void);

   Ebben az esetben, ha az trgykdot ksztnk (".) gcc-vel a
   "-nostartfiles"opcit meg kell adnunk. Ez megvja a C fordtt attl,
   hogy a .so fjljal szemben a rendszerindtsi programknyvtrakat
   satolja a programhoz. Ellenkez esetben "multiple-definition"
   (tbbszrs definci) hibt fogsz kapni. Megjegyeznk, hogy ez
   teljesen eltr attl az esettl, amikor modulokat a javasolt
   fggvnyattribtumos megoldssal fordtasz. Ksznet Jim Mischel-nek
   s Tim Gentry-nek a javaslatrt, hogy kerljn ide egy lers a _init
   s _fini-rl, s hogy segtettek elkszteni azt.
     _________________________________________________________________

5.3. Megosztott programknyvtrak, mint szkriptek

J dolog, hogy a GNU betlt engedlyezi, hogy a programknyvtrak szveges
fjlok is lehetnek, amiket egy specilis szkript nyelven kell rni a
szoksos programknyvtr-formtum helyett. Ez hasznos pldul
programknyvtrak kzvetett sszekapcsolsa esetn. Pldaknt lljon itt a
rendszerem /usr/lib/libc.so fjlja:

/* 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 )

   Tovbbi informcit tallsz errl a ld texinfo dokumentcijban a
   linker scripts szekciban (ld parancs nyelv). ltalnos informci a
   info:ld#Options and info:ld#Commands, fejezetben. Az utastsok pedig
   a info:ld#Option Commands-ban.
     _________________________________________________________________

5.4. Szimblum verzik s verzi szkriptek

A kls fggvnyekre trtn hivatkozsok jellemzen egy szksgszer
bzishoz vannak ktve, amelyek kzl nem mindegyik ktdik a kls
fggvnyhez, az alkalmazs indulsakor. (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 programknyvtr rgi, az ignyelt
interfsze hinyozhat, amikor az alkalmazs megprblja hasznlni azt. Ez
azonnali s vratlan hibt okozhat.

A problma megoldhat a szimblumok verzival val megjellsvel, s a
verzi-szkript csatolsval. Szimblum verzik hasznlatval a felhasznl
figyelmeztetst kap, ha olyan programot indt el, amely tl rgi
programknyvtrat akar hasznlni. Tbbet tudhatsz meg az ld kzknyvbl, a
[54]http://www.gnu.org/manual/ld-2.9.1/html_node/ld_25.html honlapon.
     _________________________________________________________________

5.5. GNU libtool

Ha olyan alkalmazst ksztesz amit tbb rendszerre szeretnl hasznlni,
akkor javasolt a [55]GNU libtool hasznlata a programknyvtr fordtshoz
s teleptshez. A GNU libtool egy ltalnos programknyvtr-ksztst
tmogat szkript. A Libtool elrejti a megosztott programknyvtrak
bonyolultsgt egy konzisztens s hordozhat interfsz mg. A Libtool
hordozhat interfszt biztost a trgykd fjlok ksztshez, a
programknyvtrak (statikus s megosztott), a futtathat fjlokhoz
csatolshoz, a futtathat fjlok hibakeresshez, a programknyvtrak s
futtathat fjlok teleptshez. Tartalmaz tovbb egy libltdl
programknyvtrat, ami egy hordozhat csatolfellet a dinamikusan
betlthet programknyvtrakhoz. Tbbet tudhatsz meg a
[56]http://www.gnu.org/software/libtool/manual.html honlapon tallhat
dokumentcibl.
     _________________________________________________________________

5.6. Szimblumok eltvoltsa

A generlt fjlokban tallhat szimblumok hasznosak hibakeressnl, de sok
helyet foglalnak. Ha helyre van szksged, akkor cskkentheted a szimblumok
szmt.

A legjobb eljrs elszr a trgykdokat szimblumokkal generlni s a
tesztelst s hibakaresst ezekkel vgezni, sokkal knnyebb gy. Azutn,
mikor a program mr alaposan tesztelve van a strip(1)-et hasznlhatod a
szimblumok eltvoltsra. A strip(1) utasts sok lehetsget ad arra,
hogy meghatrozd milyen szimblumokat akarsz eltvoltani. Tovbbi
rszletekrt olvasd a dokumentcit.

Egy msik lehetsg a GNU ld "-S" s "-s" kapcsolinak hasznlata. Az
"-S"'mellzi a hibakeresshez szksges szimblumokat (de nem az sszes
szimblumot). A "-s" pedig az sszes szimblum informcit kihagyja a
kimeneti fjlbl. Hasznlhatod ezeket a kapcsolkat a gcc-n keresztl is a
"-Wl,-S" s "-Wl,-s" formban. Ha sosem akarsz szimblumokat, akkor ezek a
kapcsolk megfelelek, hasznld ket. De ez a kevsb rugalmas megolds.
     _________________________________________________________________

5.7. Nagyon kicsi futtathat fjlok

Egy igen hasznos lerst tallhatsz a [57]Whirlwind Tutorial on Creating
Really Teensy ELF Executables for Linux honlapon. Ez lerja, hogyan
kszthetsz igazn parnyi futtathat fjlokat. szintn szlva a legtbb
ott tallhat trkk nem hasznlhat norml esetben, de jl mutatjk, hogy
mkdik az ELF igazbl.
     _________________________________________________________________

5.8. C++ vs. C

Semmi akadlya annak, hogy C++ programbl C programknyvtri fggvnyeket
hvj meg. A C++ kdban a C fggvny extern "C"-nek kell definilni.
Ellenkez esetben a szerkeszt (linker) nem fogja megtallni a C
fggvnyt. A C++ fordt "sztszedi" a C++ fggvnyek neveit (pldul
tpusazonosts cljbl), jelezni kell neki, hogy egy adott fggvnyt, mint
C fggvnyt kell hvnia (s gy ezt a sztszedst nem kell hasznlni).

Ha olyan programknyvtrat rsz amit C s C++-bl is hvni kell, akkor
ajnlott a megfelel header fjlba elhelyezd a 'extern "C"'utastst azrt,
hogy ezt a tulajdonsgot automatikusan biztostsd a felhasznlknak. Ha ezt
kombinlod a szoksos #ifndef-el a fjl elejn, hogy elkerld a header fjl
jrafeldolgozst, akkor ez azt jelenti, hogy egy tipikus header fjl, ami C
s C++-ban is hasznlhat (neve legyen mondjuk foobar.h) gy nz 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++ inicializci felgyorstsa

A KDE fejlesztk jeleztk, hogy nagy grafikus C++ alkalmazsok indulsa
sokig tart. Ez rszben a sok jra allokcinak ksznhet. Ltezik nhny
megolds a problmra. Tovbbi informcit [58]Waldo Bastian: Making C++
ready for the desktop cm rsban olvashatsz.
     _________________________________________________________________

5.10. Linux Standard Base (LSB)

A Linux Standard Base (LSB) projekt clja, hogy olyan szabvnyokat dolgozzon
ki s npszerstsen, amelyek nvelik a kompatibilitst a Linux
terjesztsek kztt, s lehetv teszik az alkalmazsok futtatst minden
ennek megfelel Linux rendszeren. A projekt honlapja a
[59]http://www.linuxbase.org webhelyen rhet el.

Egy szp cikk jelent meg George Kraft IV (IBM Linux Technology Center senior
szoftvermrnk) tollbl 2002 oktberben arrl, hogyan fejlessznk LSB
kompatibilis alkalmazsokat: [60]Developing LSB-certified applications: Five
steps to binary-compatible Linux applications. Termszetesen a kdot gy
kell megrni, hogy egy standardizlt rteget hasznljon, ha azt akarod, hogy
a program hordozhat legyen. Tovbb a LSB eszkzket biztost a C/C++ az
alkalmazs ksztknek, a programok LSB kompatibilitsnak ellenrzsre.
Ezek az eszkzk kihasznljk a szerkeszt (linker) nhny tulajdonsgt,
s nhny specilis programknyvtrat hasznlnak a szksges
ellenrzseknek elvgzsre. Nyilvnvalan teleptened kell ezeket az
eszkzket, ha el akarod vgezni ezeket az ellenrzseket. Az LSB honlapjn
megtallhatk. Ezt kveten egyszeren a "lsbcc" kell hasznlnod, mint
C/C++ fordtt (az lsbcc belsleg kszt egy csatolsi krnyezetet, ami
jelezni fogja, ha bizonyos LSB szablyok srlnek):

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

Az lsbappchk programot arra hasznlhatod, hogy ellenrizd a program valban
csak az LSB ltal standardizlt fggvnyeket hasznlja:

    $ lsbappchk myapplication

   Az LSB csomagolsi tmutatt is kvetned kell (pl. hasznlj RPM v3-at,
   hasznlj LSB ltal meghatrozott csomagneveket, s az add-on
   szoftvereket az /opt-ba kell teleptened alaprtelmezetten). Tovbbi
   informcikat a cikkben s az LSB honlapjn tallsz.
     _________________________________________________________________

6. Tovbbi pldk

Az albbi pldk mindhrom programknyvtr tpussal foglalkoznak (statikus,
megosztott s dinamikus programknyvtrak). A libhello.c fjl egy trivilis
programknyvtr, a libhello.h header-rel. A demo_use.c fjl egy trivilis
program, ami a programknyvtrat hasznlja. Ezt kvetik a dokumentlt
szkriptek (script_static s script_dynamic), amik bemutatjk, hogyan
hasznlhatod a programknyvtrat megosztott illetve statikus
programknyvtrknt. Ezutn a demo_dynamic.c fjljal s a script_dynamic
szkripttel megmutatjuk, hogyan hasznlhatod a megosztott programknyvtrat,
mint dinamikusan betltet programknyvtrat.
     _________________________________________________________________

6.1. libhello.c fjl

/* libhello.c - demonstrate library use. */

#include <stdio.h>

void hello(void) {
  printf("Hello, library world.\n");
}
     _________________________________________________________________

6.2. libhello.h fjl

/* libhello.h - demonstrate library use. */


void hello(void);
     _________________________________________________________________

6.3. demo_use.c fjl

/* demo_use.c -- demonstrate direct use of the "hell routine */

#include "libhello.h"

int main(void) {
 hello();
 return 0;
}
     _________________________________________________________________

6.4. script_static fjl

#!/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 fjl

#!/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 fjl

/* demo_dynamic.c -- demonstrate dynamic loading and
   use of the "hell 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.s, RTLD_LAZY);
 if (!module) {
   fprintf(stderr, "Couldn't open libhello.so: %s\n",
           dlerror());
   exit(1);
 }

 /* Get symbol */
 dlerror();
 demo_function = dlsym(module, "hell);
 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 fjl

#!/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
     _________________________________________________________________

7. Tovbbi informci

Tovbbi hasznos informcikat tallsz a programknyvtrakrl a kvetkez
forrsokban:

     * Daniel Barlow: "The GCC HOWT. Ez a HOGYAN klnsen a fordt
       (compiler) kapcsolkat trgyalja, amivel programknyvtrakat
       kszthetnk. Olyan informcikat tartalmaz amivel itt nem
       foglalkoztunk s viszont. A HOGYAN a Linux Documantation Project
       oldaln keresztl rhet el: [61]http://www.tldp.org.
     * Tool Interface Standards (TIS) biztosg: "Executable and Linkable
       Format (ELF)" (ez jelenleg egy fejezete a Portable Formats
       Specification Version 1.1.-nek ugyanettl a bizottsgtl). Ez az
       ELF formtumrl tartalmaz nagy mennyisg s rszletes
       informcit (ami nem Linux vagy GNU gcc specifikus). Lsd:
       [62]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz Ha
       az MIT-rl szeded le a fjlt, akkor kicsomagols utn egy "hps"
       llomnyt fogsz kapni. Csak trld az els s utols sort, majd
       nevezd t "ps"-re s egy nyomtathat Postscript llomnyt kapsz a
       szoksos fjlnvvel.
     * Hongjui Lu: "ELF: From the Programmer's Perspective" . Linux s
       GNU specifikus informcikat tartalmaz a ELF-rl, a
       [63]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
       webhelyen rhet el.
     * Az ld dokumentcija: "Using LD, the GNU Linker" rja le az ld-t
       messze a legrszletesebben. A
       [64]http://www.gnu.org/manual/ld-2.9.1 webhelyen rhet el.
     _________________________________________________________________

8. Copyright and License

This document is Copyright (C) 2000 David A. Wheeler. It is covered by the
GNU General Public License (GPL). You may redistribute it without cost.
Interpret the document's source text as the ``program'' and adhere to the
following terms:

     This program is free software; you can redistribute it and/or
     modify it under the terms of the GNU General Public License as
     published by the Free Software Foundation; either version 2 of the
     License, or (at your option) any later version.

     This program is distributed in the hope that it will be useful, but
     WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
     General Public License for more details.

     You should have received a copy of the GNU General Public License
     along with this program; if not, write to the Free Software
     Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
     USA

These terms do permit mirroring by other web sites, but please:

     * make sure your mirrors automatically get upgrades from the master
       site,
     * clearly show the location of the master site,
       [65]http://www.dwheeler.com/program-library, with a hypertext link
       to the master site, and
     * give me (David A. Wheeler) credit as the author.

   The first two points primarily protect me from repeatedly hearing
   about obsolete bugs. I do not want to hear about bugs I fixed a year
   ago, just because you are not properly mirroring the document. By
   linking to the master site, users can check and see if your mirror is
   up-to-date. I'm sensitive to the problems of sites which have very
   strong security requirements and therefore cannot risk normal
   connections to the Internet; if that describes your situation, at
   least try to meet the other points and try to occasionally sneakernet
   updates into your environment.

   By this license, you may modify the document, but you can't claim that
   what you didn't write is yours (i.e., plagiarism) nor can you pretend
   that a modified version is identical to the original work. Modifying
   the work does not transfer copyright of the entire work to you; this
   is not a ``public domain'' work in terms of copyright law. See the
   license for details, in particular noting that ``You must cause the
   modified files to carry prominent notices stating that you changed the
   files and the date of any change.'' If you have questions about what
   the license allows, please contact me. In most cases, it's better if
   you send your changes to the master integrator (currently David A.
   Wheeler), so that your changes will be integrated with everyone else's
   changes into the master copy.

References

   1. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#INTRODUCTION
   2. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN26
   3. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#STATIC-LIBRARIES
   4. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#SHARED-LIBRARIES
   5. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN52
   6. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN76
   7. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN83
   8. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN101
   9. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN121
  10. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN141
  11. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#DL-LIBRARIES
  12. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#DLOPEN
  13. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#DLERROR
  14. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#DLSYM
  15. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#DLCLOSE
  16. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#DL-LIBRARY-EXAMPLE
  17. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#MISCELLANEOUS
  18. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#NM
  19. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#INIT-AND-CLEANUP
  20. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#SHARED-SCRIPTS
  21. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#VERSION-SCRIPTS
  22. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#GNU-LIBTOOL
  23. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#REMOVING-SYMBOLS
  24. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#SMALL-EXECUTABLES
  25. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#CPP-VS-C
  26. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#SPEEDING-CPP-INIT
  27. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#LSB
  28. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#MORE-EXAMPLES
  29. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN286
  30. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN290
  31. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN294
  32. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN298
  33. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN302
  34. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN306
  35. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#AEN310
  36. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#INFO-SOURCES
  37. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#COPYRIGHT
  38. http://www.gnu.org/software/libtool/libtool.html
  39. http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html
  40. http://www.dwheeler.com/program-library
  41. http://www.tldp.org/
  42. mailto:szferi[kukac]angel.elte[pont]hu
  43. mailto:dacas@freemail.hu_NO_SPAM
  44. http://tldp.fsf.hu/index.html
  45. info:standards#Directory_Variables
  46. http://www.pathname.com/fhs
  47. http://www.visi.com/~barr/ldpath.html
  48. http://www.trolltech.com/developer/faq/tech.html#bincomp
  49. http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html
  50. http://www.gnu.org/software/libtool/libtool.html
  51. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#init-and-cleanup
  52. file://localhost/home/dacas/convert/Program-Library-HOWTO-hu.html#init-and-cleanup
  53. info:binutils#nm
  54. http://www.gnu.org/manual/ld-2.9.1/html_node/ld_25.html
  55. http://www.gnu.org/software/libtool/libtool.html
  56. http://www.gnu.org/software/libtool/manual.html
  57. http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
  58. http://www.suse.de/~bastian/Export/linking.txt
  59. http://www.linuxbase.org/
  60. http://www-106.ibm.com/developerworks/linux/library/l-lsb.html?t=gr,lnxw02=LSBapps
  61. http://www.tldp.org/
  62. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz
  63. ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
  64. http://www.gnu.org/manual/ld-2.9.1
  65. http://www.dwheeler.com/program-library
