Programk�nyvt�r HOGYANDavid A. Wheeler

v1.20, 2003. �prilis 11.

   Ez a HOGYAN azoknak a programoz�knak k�sz�lt, akik programk�nyvt�rakat
   szeretn�nek haszn�lni Linuxon. �sszefoglalja a programk�nyvt�rak
   k�sz�t�s�t �s haszn�lat�t. Egyar�nt tartalmazza a statikus (static),
   megosztott (shared), valamint a dinamikusan bet�lthet� (dynamically
   loaded) programk�nyvt�rakkal kapcsolatos ismereteket.
     _________________________________________________________________

   Tartalomjegyz�k
   1. [1]Bevezet�s

        1.1. [2]Magyar ford�t�s

   2. [3]Statikus programk�nyvt�rak
   3. [4]Megosztott programk�nyvt�rak

        3.1. [5]Konvenci�k
        3.2. [6]Hogyan haszn�ljuk a programk�nyvt�rakat?
        3.3. [7]K�rnyezeti v�ltoz�k
        3.4. [8]Megosztott programk�nyvt�rak k�sz�t�se
        3.5. [9]Megosztott programk�nyvt�rak telep�t�se �s haszn�lata
        3.6. [10]Inkompatibilis programk�nyvt�rak

   4. [11]Dinamikusan bet�lthet� (Dynamically Loaded; DL)
          programk�nyvt�rak

        4.1. [12]dlopen()
        4.2. [13]dlerror()
        4.3. [14]dlsym()
        4.4. [15]dlclose()
        4.5. [16]DL programk�nyvt�r p�lda

   5. [17]Egy�b

        5.1. [18]nm utas�t�s
        5.2. [19]Programk�nyvt�r konstruktor �s destruktor f�ggv�nyek
        5.3. [20]Megosztott programk�nyvt�rak, mint szkriptek
        5.4. [21]Szimb�lum verzi�k �s verzi� szkriptek
        5.5. [22]GNU libtool
        5.6. [23]Szimb�lumok elt�vol�t�sa
        5.7. [24]Nagyon kicsi futtathat� f�jlok
        5.8. [25]C++ vs. C
        5.9. [26]A C++ inicializ�ci� felgyors�t�sa
        5.10. [27]Linux Standard Base (LSB)

   6. [28]Tov�bbi p�ld�k

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

   7. [36]Tov�bbi inform�ci�
   8. [37]Copyright and License

1. Bevezet�s

Ez a HOGYAN programoz�knak k�sz�lt, �s �sszefoglalja, hogyan k�sz�thetsz �s
haszn�lhatsz programk�nyvt�rakat Linuxon, a GNU eszk�zk�szlet
felhaszn�l�s�val. A "programk�nyvt�r" kifejez�s egyszer�en egy olyan f�jlt
jel�l, ami leford�tott t�rgyk�dot (�s adatot) tartalmaz, amit k�s�bb egy
programmal �ssze lehet szerkeszteni (link). A programk�nyvt�rak lehet�v�
teszik, hogy az alkalmaz�s modul�risabb, gyorsabban �jraford�that� �s
k�nnyebben friss�thet� legyen. A programk�nyvt�rakat h�rom t�pusba
sorolhatjuk: statikus programk�nyvt�rak, megosztott programk�nyvt�rak �s
dinamikusan bet�lthet� (DL) programk�nyvt�rak.

Ez a le�r�s el�sz�r a statikus programk�nyvt�rakkal foglalkozik, melyeket a
program futtat�sa el�tt kell az alkalmaz�shoz szerkeszteni. Ezt k�vet�en
foglalkozik a megosztott (shared) programk�nyvt�rakkal, amelyek a program
indul�sakor t�lt�dnek be, �s t�bb program k�z�tt megoszthat�ak. V�g�l pedig
a dinamikusan bet�lthet� (DL) programk�nyvt�rakr�l lesz sz�, amiket a
programv�grehajt�s alatt t�lthet�nk be. A DL programk�nyvt�rak nem igaz�n
t�rnek el form�tumban a m�sik k�t programk�nyvt�r-t�pust�l (mind statikus,
mind megosztott programk�nyvt�rak lehetnek DL programk�nyvt�rak), a
k�l�nbs�g abb�l ad�dik, hogyan haszn�lj�k a programoz�k a DL
programk�nyvt�rakat. A HOGYAN egy fejezetnyi p�ld�val �s egy fejezetnyi
hivatkoz�ssal z�rul.

Minden programoz�nak, aki programk�nyvt�rakat fejleszt elvileg megosztott
programk�nyvt�rakat kellene k�sz�tenie az�rt, hogy lehet�v� tegye a
felhaszn�l�knak a programk�nyvt�rak alkalmaz�st�l f�ggetlen friss�t�s�t. A
dinamikusan bet�lthet� (DL) programk�nyvt�rak hasznosak, de kicsivel t�bb
munk�t ig�nyel a haszn�latuk, �s sok programnak nincs sz�ks�ge arra a
rugalmass�gra amit ny�jtanak. Ezzel szemben a statikus programk�nyvt�rak
sokkal k�r�lm�nyesebb� teszik a friss�t�st. Ez�rt ritk�n aj�nlott a
haszn�latuk. Ezzel egy�tt mindegyik programk�nyvt�r-t�pusnak van el�nye,
mely el�ny�ket egy-egy fejezetben foglaljuk �ssze a k�s�bbiekben. A
dinamikusan bet�lthet� (DL) programk�nyvt�rakat haszn�l� C++ fejleszt�knek
a "C++ dlopen mini-HOGYAN" is aj�nlott olvasm�ny.

El�g szerencs�tlen, hogy j� n�h�nyan a dinamikusan szerkesztett (linked)
programk�nyvt�rak (DLL-ek) kifejez�st haszn�lj�k a megosztott
programk�nyvt�rakra. M�sok ugyanezt a kifejez�st b�rmely olyan
programk�nyvt�rra haszn�lj�k, mely dinamikusan bet�lthet�. Megint m�sok a
DLL-t a programk�nyvt�rakra haszn�lj�k megk�t�sek n�lk�l. F�ggetlen�l att�l,
hogy te mit �rtesz alatta, ez a HOGYAN a DLL-ekkel foglalkozik Linuxon.

A HOGYAN csak a ELF (Executable and Linking Format) form�tum� futtathat�
f�jlokkal �s programk�nyvt�rakkal foglalkozik. Ezt a form�tumot haszn�lja a
legt�bb Linux terjeszt�s. A GNU gcc eszk�zk�szlet ett�l elt�r�
form�tumokat is k�pes kezelni, p�ld�ul a legt�bb Linux terjeszt�s m�g mindig
haszn�lja az elavult a.out form�tumot. Ugyanakkor ez a form�tum k�v�l esik
ennek a HOGYANnak a t�mak�r�n.

Ha hordozhat� alkalmaz�s szeretn�l k�sz�teni, akkor megfontoland� a [38]GNU
libtool haszn�lata. Ebben az esetben a programk�nyvt�rakat ezzel az
eszk�zzel k�sz�ted �s telep�ted, a linuxos eszk�z�k k�zvetlen haszn�lata
helyett. A GNU libtool egy �ltal�nos programk�nyvt�r-k�sz�t�st �s telep�t�st
t�mogat� szkript-k�szlet, ami konzisztens �s hordozhat� fel�lettel rejti el
a megosztott programk�nyvt�rak haszn�lat�nak bonyolults�g�t. Linuxon a GNU
libtool azokra az eszk�z�kre �s egyezm�nyekre �p�l k�zvetlen�l, melyeket ez
a HOGYAN t�rgyal. Sz�mtalan hordozhat�s�got biztos�t� illeszt�fel�let
(wrapper) l�tezik dinamikusan bet�lthet� programk�nyvt�rakhoz is. A GNU
libtool tartalmaz egy ilyen illeszt�fel�let programk�nyvt�rat "libltdl"
n�ven. Egy m�sik alternat�va lehet a glib programk�nyvt�r haszn�lata (nem
�sszekeverend� a glibc-vel), ami hordozhat� t�mogat�st ny�jt a dinamikusan
bet�lthet� modulokhoz. Tov�bbi inform�ci�t a
[39]http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.
html honlapon tal�lsz. M�g egyszer: Linuxon ez a funkci� az ebben a
HOGYANban le�rt m�dszerekkel is megval�s�that�. Ha jelenleg Linuxon
fejlesztesz vagy hib�t keresel, akkor val�sz�n�leg az ebben a HOGYANban
tal�lhat� inform�ci�kra lesz sz�ks�ged.

A [40]http://www.dwheeler.com/program-library webhely a k�zponti el�r�si
helye a HOGYANnak (angol verzi�), az elk�sz�t�s�ben k�zrem�k�d�tt a The
Linux Documentation Project ([41]http://www.tldp.org). A szerz�i jogokat
David A. Wheeler birtokolja Copyright (C) 2000, a dokumentumra a General
Public License (GPL) �rv�nyes; tov�bbi inform�ci�t az utols� fejezetben
tal�lsz err�l.
     _________________________________________________________________

1.1. Magyar ford�t�s

A magyar ford�t�st [42]Szalai Ferenc Attila k�sz�tette (2003.12.11). A
lektor�l�st [43]Daczi L�szl� v�gezte el (2004.03.01). A dokumentum
legfrissebb v�ltozata megtal�lhat� a [44]Magyar Linux Dokument�ci�s Projekt
honlapj�n.
     _________________________________________________________________

2. Statikus programk�nyvt�rak

A statikus programk�nyvt�rak k�z�ns�ges t�rgyk�d-f�jlok gy�jtem�nyei.
Meg�llapod�s szerint a statikus programk�nyvt�rak ".a" kiterjeszt�ssel
v�gz�dnek. Egy ilyen gy�jtem�ny az ar (archiver) programmal k�sz�thet�. A
statikus programk�nyvt�rakat ma m�r nem haszn�lj�k olyan gyakran, mint
r�gebben, figyelembe v�ve a megosztott programk�nyvt�rak el�nyeit (l�sd
lejjebb). N�ha azonban, m�g mindig k�sz�tenek ilyeneket. T�rt�nelmileg �k
jelentek meg el�sz�r, �s egyszer�bb is elmagyar�zni m�k�d�s�ket.

A statikus programk�nyvt�rak lehet�v� teszik a felhaszn�l�knak, hogy
�jraford�t�s n�lk�l szerkessz�k �ket a programokhoz, ezzel ler�vid�tve a
ford�t�si id�t. Megjegyezz�k, hogy a mai gyors ford�t�k mellett a
�jraford�t�si id� kev�sb� fontos szempont, �gy ez ma m�r nem olyan er�s
�rv, mint r�gebben. A statikus programk�nyvt�rak gyakran hasznosak azoknak a
fejleszt�knek, akik lehet�v� akarj�k tenni a programoz�k sz�m�ra, hogy
szerkessz�k a programjukat a programk�nyvt�rukhoz, de nem akarj�k a
programoz�k rendelkez�s�re bocs�tani a programk�nyvt�r forr�s�t. (Ez
el�ny�s lehet a programk�nyvt�r forgalmaz�j�nak, de nyilv�nval�an h�tr�nyos
annak a programoz�nak, aki azt haszn�lni szeretn�). Elm�letileg a programhoz
csatolt statikus ELF programk�nyvt�rban l�v� k�d kiss� gyorsabban (1-5%-al)
futhat, mint a megosztott vagy dinamikusan bet�lthet� programk�nyvt�rban
l�v�. Gyakorlatilag ez ritk�n ad okot a statikus programk�nyvt�rak
haszn�lat�ra, az egy�b zavar� t�nyez�k miatt.

A statikus programk�nyvt�r k�sz�t�s�hez, vagy a m�r megl�v� program
k�nyv�rhoz �j t�rgyk�d-f�jlok hozz�ad�s�hoz az al�bbi utas�t�st haszn�ljuk:

ar rcs my_library.a file1.o file2.o

   Ez az egyszer� utas�t�s hozz�adja a file1.o �s file2.o
   t�rgyk�d-f�jlokat a my_library.a statikus programk�nyvt�rhoz.
   L�trehozza a my_library.a f�jlt, ha az nem l�tezett. Tov�bbi
   inform�ci�kat a statikus programk�nyvt�rak k�sz�t�s�r�l az ar(1)-ben
   tal�lsz.

   Ha elk�sz�tett�l egy statikus programk�nyvt�rat nyilv�n haszn�lni is
   akarod. �gy haszn�lhatod a statikus programk�nyvt�rat, hogy hivatkozol
   r� ford�t�si �s szerkeszt�si folyamatnak abban a f�zis�ban, amikor a
   program futtathat� f�jlja k�sz�l. Ha gcc(1)-et haszn�lsz a futtathat�
   f�jl k�sz�t�s�re, akkor a -l opci�val �rhatod el� haszn�lni k�v�nt
   programk�nyvt�rak programhoz szerkeszt�s�t. Tov�bbi inform�ci�t az
   info:gcc-ben tal�lsz.

   L�gy �vatos a param�terek sorrendj�vel, ha gcc-t haszn�lsz. Mivel a -l
   a szerkeszt� (linker) kapcsol�ja, �gy azt a ford�tand� f�jl neve UT�N
   tedd. Ez egy kicsit k�l�nb�zik a norm�lis kapcsol�megad�si
   szintaxist�l. Ha a f�jl el� teszed a -l opci�t, akkor a csatol�s
   t�k�letesen hib�s lesz �s misztikus hib�kat eredm�nyez.

   Haszn�lhatod a linker programot ld(1) k�zvetlen�l is a -l �s -L
   opci�kkal, de a legt�bb esetben jobb a gcc(1)-t haszn�lni, mivel az
   ld(1) interf�sze nagyobb val�sz�n�s�ggel v�ltozik, mint a gcc
   ford�t��.
     _________________________________________________________________

3. Megosztott programk�nyvt�rak

Megosztott programk�nyvt�rak olyan programk�nyvt�rak, amiket a program
indul�sakor t�lt be. Ha a megosztott programk�nyvt�rak megfelel�en vannak
telep�tve, az �sszes program az indul�sa ut�n automatikusan �j megosztott
programk�nyvt�rat haszn�l. Ez enn�l egy kicsit rugalmasabb �s bonyolultabb
jelenleg, mert a linuxos megold�s megengedi azt is, hogy:

     * friss�tsd a programk�nyvt�raidat �s k�zben t�mogasd azokat a
       programokat is, amik a r�gebbi v�ltozatait haszn�lj�k azoknak a
       programk�nyvt�raknak, amik visszafele nem kompatibilisek.
     * fel�lb�r�lj specifikus programk�nyvt�rakat vagy f�ggv�nyeket a
       programk�nyvt�rban k�l�nleges programok futtat�sakor.
     * mindezt a programok fut�sa k�zben tegyed, mik�zben azok a m�r
       l�tez� programk�nyvt�rakat haszn�lj�k.
     _________________________________________________________________

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.1.1. Megosztott programk�nyvt�rak nevei

Minden megosztott programk�nyvt�rnak van egy speci�lis neve, amit
"so-n�v"-nek h�vnak. Az so-n�vnek van egy "lib" el�tagja, ezt k�veti a
programk�nyvt�r neve, majd egy ".s� tag majd egy pont, �s a verzi�sz�m (egy
speci�lis kiv�tel az alacsony szint� C programk�nyvt�rak, amik nem
kezd�dnek "lib"-el). A verzi�sz�m akkor n�vekedik, ha az interf�sz
v�ltozik. A "teljes so-n�v" tartalmazza el�tagk�nt a k�nyvt�r (directory)
nev�t, amiben a programk�nyvt�r tal�lhat�. Egy m�k�d� rendszeren a teljes
so-n�v egyszer�en egy szimbolikus hivatkoz�s a megosztott programk�nyvt�r
val�di nev�re.

Minden megosztott programk�nyvt�rnak van "val�di neve" is, ami annak az
f�jlnak a neve, ami a jelenlegi programk�nyvt�r k�dj�t tartalmazza. A val�di
n�v az so-n�vhez ad egy pontot, a minor sz�mot, egy �jabb pont-ot �s a
kibocs�t�si sz�mot (release number). Az utols� pont �s a kibocs�t�si sz�m
opcion�lis. A minor sz�m �s a kibocs�t�si sz�m arra val�, hogy tudd,
pontosan melyik v�ltozata van az adott programk�nyvt�rnak telep�tve.
Megjegyezz�k, hogy ezek a sz�mok nem felt�tlen�l egyeznek meg azzal, amilyen
verzi�sz�mmal a programk�nyvt�r dokument�ci�j�ban hivatkoznak, hab�r az
megk�nny�ten� a dolgokat.

Van tov�bb� egy n�v, amit a ford�t�sn�l haszn�lunk, amikor a
programk�nyvt�rra hivatkozunk (ezt "csatol�si n�v"-nek fogjuk h�vni). Ez
egyszer�en a so-n�v verzi� n�lk�l.

A megosztott programk�nyvt�rak haszn�lat�nak kulcsa a neveik
sz�tv�laszt�s�ban rejlik. A programokban a sz�ks�ges megosztott
programk�nyvt�rak so-neveire van csak sz�ks�g. Ennek megfelel�en, amikor
egy megosztott programk�nyvt�rat k�sz�tesz, mind�ssze egy programk�nyvt�rat
k�sz�tesz egy speci�lis f�jln�ven (r�szletes verzi� inform�ci�kkal). Amikor
telep�ted az �j v�ltozat�t a programk�nyvt�rnak, akkor a megfelel�
k�nyvt�rak egyik�be kell elhelyezned �s az ldconfig(8) programot kell
futtatnod. Az ldconfig megvizsg�lja a l�tez� f�jlokat �s elk�sz�ti a
so-neveket, mint szimbolikus hivatkoz�sokat a val�di nevekre, ezzel egy�tt
be�ll�tja az /etc/ld.so.cache gyorst�r-f�jlt is.

Az ldconfig nem �ll�tja be a szerkeszt�si neveket, �ltal�ban ez megt�rt�nt
m�r a programk�nyvt�r telep�t�se sor�n, a szerkeszt�si n�v egyszer�en egy
szimbolikus hivatkoz�s a "leg�jabb" so-n�vre vagy a leg�jabb val�di n�vre.
Az tan�csoln�m legyen a csatol�si n�v egy szimbolikus hivatkoz�s az
so-n�vre, mivel a legt�bb esetben a friss�tett programk�nyvt�rat szeretn�d
automatikusan haszn�lni, mikor csatolod azt a programodhoz. Megk�rdeztem H.
J,. Lu-t, mi�rt nem �ll�tja be automatikusan az ldconfig a szerkeszt�si
neveket. A magyar�zata alapvet�en az volt, hogy tal�n a programk�nyvt�r
legut�bbi verzi�j�t szeretn�d futtatni a k�ddal, de az is lehet, hogy egy
fejleszt�i v�ltozatra szeretn�l hivatkoz�st egy r�gi - tal�n inkompatibilis
- programk�nyvt�r helyett. Ez�rt az ldconfig nem k�s�rli meg kital�lni, hogy
mit akarsz a programhoz csatolni, �gy a telep�t�nek kell meghat�rozni azt,
�s m�dos�tani a szimbolikus hivatkoz�st arra a programk�nyvt�rra, amit a
szerkeszt� haszn�lni fog.

�gy az /usr/lib/libreadline.so.3 egy teljes so-n�v, amit az ldconfig
k�sz�tett, p�ld�ul mint szimbolikus hivatkoz�st a
/usr/lib/libreadline.so.3.0 f�jlra. Kellene lennie egy
/usr/lib/libreadline.so szerkeszt�si n�vnek is, ami egy szimbolikus
hivatkoz�s lehet a /usr/lib/libreadline.so.3 f�jlra.
     _________________________________________________________________

3.1.2. Elhelyez�s a f�jlrendszerben

A megosztott programk�nyvt�rakat el kell helyezni valahol a f�jlrendszerben.
A legt�bb ny�lt forr�s� szoftver a GNU szabv�nyok (standards) k�vet�s�re
t�rekszik. Tov�bbi inform�ci�t az [45]info:standards#Directory_Variables
info dokumentumban tal�lhatsz. A GNU szabv�nyok azt aj�nlj�k, hogy
alap�rtelmez�sben minden programk�nyvt�rat az /usr/local/lib k�nyvt�rba
telep�ts�nk a forr�sk�d k�zz�t�telekor (�s minden parancsnak az
/usr/local/bin k�nyvt�rba kellene ker�lnie). Ezek a szabv�nyok konvenci�kat
is meghat�roznak arra vonatkoz�lag, hogyan b�r�ljuk fel�l ezt az
alap�rtelmezett be�ll�t�st a telep�t�si elj�r�s sor�n.

A Filesystem Hierarchy Standard (FHS) meghat�rozza mi hol legyen egy
terjeszt�sben (l�sd: [46]http://www.pathname.com/fhs). Az FHS szerint a
legt�bb programk�nyvt�rat az /usr/lib k�nyvt�rba kell telep�teni, de azokat
amik az elindul�shoz sz�ks�gesek a /lib k�nyvt�rban kellene lenni�k, �s azok
a k�nyvt�rak, melyek nem r�szei a rendszernek azokat kellene a
/usr/local/lib k�nyvt�rba rakni.

Nincs igaz�n ellentmond�s a k�t dokumentum k�z�tt. A GNU szabv�nyok a
fejleszt�knek, m�g az FHS a terjeszt�st �ssze�ll�t�knak (akik szelekt�ven
fel�lb�r�lj�k a forr�s alap�rtelmezett be�ll�t�sait, rendszerint a rendszer
csomagkezel�j�vel) sz�l� aj�nl�sok. Gyakorlatilag ez sz�pen m�k�dik: a
"leg�jabb" (val�sz�n�leg hib�s!) forr�st, amit let�ltesz, automatikusan a
"local" k�nyvt�rba (/usr/local) telep�ti mag�t, azokn�l a k�dokn�l, amik
"meg�rtek" a csomag kezel�k mag�t�l �rthet�dben fel�lb�r�lj�k az
alap�rtelmezett be�ll�t�sokat, �s elhelyezik a k�dot az alap�rtelmezett
hely�re a terjeszt�sben. Megjegyezz�k, hogy ha a programk�nyvt�rad megh�v
olyan programokat, amik csak a programk�nyvt�rak �ltal h�vhat�ak, akkor
ezeket a programokat a /usr/local/libexec (ami /usr/libexec a Linux
terjeszt�sekben) kell elhelyezni. A Red Hat alap� rendszerek egy
saj�toss�ga, hogy az /usr/local/lib k�nyvt�r nincs az alap�rtelmezett
programk�nyvt�r-keres�si �tvonalban (l�sd a megjegyz�seket az
/etc/ld.so.conf f�jlr�l lejjebb). Egy m�sik szokv�nyos programk�nyvt�r-hely
az /usr/X11R6/lib, ahova az X-winodows rendszerrel kapcsolatos
programk�nyvt�rakat szok�s elhelyezni. Megjegyezz�k, hogy a /lib/security a
PAM modulok �ltal haszn�lt hely, de ezek rendszerint DL programk�nyvt�rak
(l�sd lejjebb).
     _________________________________________________________________

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.3.1. LD_LIBRARY_PATH

�tmenetileg helyettes�thetsz n�h�ny programk�nyvt�rat bizonyos programok
futtat�sakor. Linuxon a LD_LIBRARY_PATH k�rnyezeti v�ltoz� egy
kett�sponttal elv�lasztott list�ja azoknak az el�r�si utaknak, ahol a
programk�nyvt�rakat keresi, a szok�sos helyek el�tt. Ez hasznos
hibakeres�skor, ha egy �j vagy nem szokv�nyos programk�nyvt�rat haszn�lunk
valamilyen speci�lis c�lb�l. Az LD_PRELOAD k�rnyezeti v�ltoz� egy
kett�sponttal elv�lasztott list�ja azoknak a megosztott
programk�nyvt�raknak, amelyek f�ggv�nyei fel�ldefini�lj�k a standard
programk�nyvt�rak�t, mint ahogy azt az /etc/ld.so.preload teszi. Meg kell
eml�ten�nk, hogy a LD_LIBRARY_PATH haszn�lhat� majdnem minden Unix-szer�
rendszeren, de nem mindegyiken. P�ld�ul ez a funkci� el�rhet� HP-UX-on, de
a k�rnyezeti v�ltoz� neve SHLIB_PATH. AIX-on ezt a funkci�t a LIBPATH nev�
v�ltoz�val �rhetj�k el (ugyanezzel a szintaxissal, kett�sponttal
elv�lasztott lista).

LD_LIBRARY_PATH k�nyelmes fejleszt�sn�l vagy tesztel�sn�l, de sz�ks�gtelen
m�dos�tania egy norm�l felhaszn�l�nak vagy ak�r egy telep�t�si elj�r�snak
norm�l esetben. A mi�rtekr�l a "Why LD_LIBRARY_PATH is Bad" c�m� �r�sban,
a [47]http://www.visi.com/~barr/ldpath.html honlapon olvashatsz. Ezek
ellen�re haszn�lhat� fejleszt�skor vagy tesztel�skor, vagy ha egy probl�ma
behat�rol�sa nem megy m�sk�ppen. Ha nem akarod be�ll�tani a LD_LIBRARY_PATH
k�rnyezeti v�ltoz�t, akkor Linuxon k�zvetlen�l futtathatod a
programbet�lt�t, megfelel� argumentumokkal. Az al�bbi p�ld�ban a PATH-ot
fogja haszn�lni az LD_LIBRARY_PATH k�rnyezeti v�ltoz� tartalma helyett, �gy
futtatja a megadott f�jlt.

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

Az ld-linux.so argumentum n�lk�l futtatva tov�bbi inform�ci�kat add arr�l,
hogyan haszn�lhatod, de m�g egyszer hangs�lyozom, hogy norm�l k�r�lm�nyek
k�z�tt ne haszn�ld ezt, kiz�r�lag hibakeres�sre.
     _________________________________________________________________

3.3.2. LD_DEBUG

M�sik hasznos k�rnyezeti v�ltoz� az LD_DEBUG, a GNU C bet�lt�ben. Ez a
v�ltoz� arra k�nyszer�ti a dl* f�ggv�nyeket, hogy b�s�ges inform�ci�t
adjanak arr�l, hogy mit csin�lnak. P�ld�ul:

  export LD_DEBUG=files
  command_to_run

megjelen�ti a f�jlok �s programk�nyvt�rak feldolgoz�s�t, mikor a
programk�nyvt�rakat kezeli. Megjelen�ti, milyen f�gg�s�geket tal�lt a
rendszer, �s milyen so-k lesznek bet�ltve, milyen sorrendben. Az LD_DEBUG-t
"bindings"-re �ll�tva inform�ci�kat kapunk a szimb�lum k�t�s�r�l. A "libs"
be�ll�t�s a programk�nyvt�rak keres�si �tvonal�t mutatja. A "versions"
be�ll�t�s pedig a verzi� f�gg�s�geket jelen�ti meg.

   Az LD_DEBUG-ot "help"-re �ll�t�sa ut�n, ha megpr�b�lunk futtatni egy
   programot, a rendszer megjelen�ti a lehets�ges be�ll�t�sokat (a
   programot nem futtatja le). M�g egyszer megjegyezz�k, hogy az
   LD_DEBUG-ot nem norm�l haszn�latra tervezt�k, de nagyon hasznos lehet
   hibakeres�sn�l �s tesztel�sn�l.
     _________________________________________________________________

3.3.3. Tov�bbi k�rnyezeti v�ltoz�k

Sz�mos m�s k�rnyezeti v�ltoz� is van, ami a bet�lt�si elj�r�st szab�lyozza.
Ezek LD_ vagy RTLD_ el�tagokkal kezd�dnek. A legt�bb alacsony szint�
hibakeres�st tesz lehet�v� a bet�lt�si elj�r�sban, vagy speci�lis
tulajdons�gok megval�s�t�s�t teszik lehet�v�. A legt�bb nem t�l j�l
dokument�lt. Ha sz�ks�ged van r�juk legjobb, ha elolvasod a bet�lt�
forr�sk�dj�t, ha t�bbet akarsz megtudni ezekr�l a k�rnyezeti v�ltoz�kr�l.

A felhaszn�l�i beavatkoz�s enged�lyez�se a dinamikusan csatolt
programk�nyvt�rak bet�lt�s�n�l katasztrof�lis eredm�nyre vezethet,
setuid/setgid-es programok eset�n. Ez�rt a GNU bet�lt�ben (ami bet�lti a
program t�bbi r�sz�t annak indul�sakor), ha a program setuid vagy setgid
be�ll�t�sokkal rendelkezik, akkor az eddig eml�tett �s a t�bbi hasonl�
k�rnyezeti v�ltoz� vagy figyelmen k�v�l marad, vagy hat�sa er�sen
korl�tozva lesz. Ha az uid �s az euid, vagy ha a gid �s a egid k�l�nb�zik, a
bet�lt� felt�telezi, hogy a program setuid vagy setgid-es (vagy annak
gyermeke), ez�rt jelent�sen cs�kkenti a csatol�s kontroll�l�s�nak
lehet�s�g�t k�rnyezeti v�ltoz�kkal. Ha a GNU glibc programk�nyvt�r
forr�sk�dj�t olvasod, l�thatod ezt, k�l�n�sen az elf/rtlf.c �s a
sysdeps/generic/dl-sysdep.c f�jlokat olvasva. Ez azt jelenti, ha el�red,
hogy a uid �s a euid, valamit a gid �s egid megegyezzenek ezek a v�ltoz�k
kifejtik teljes hat�sukat, mikor a programot futtatod. M�s Unix-szer�
rendszerek hasonl� okb�l kifoly�lag, de m�shogy kezelik ezt a probl�m�t: a
setuid �s setgid-es programot indokolatlanul nem befoly�solhatjuk k�rnyezeti
v�ltoz�kkal.
     _________________________________________________________________

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 ".s�-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.

   Vigy�zat: ne futtasd az ldd-t olyan programra, amiben nem b�zol. Ahogy
   az vil�gosan le van �rva az ldd(1) k�zik�nyv�ben, az ldd �gy m�k�dik
   (a legt�bb esetben), hogy be�ll�t egy speci�lis k�rnyezeti v�ltoz�t
   (ELF t�rgyk�dok eset�n az LD_TRACE_LOADED_OBJECTS-et) �s futtatja a
   programot. Lehets�ges egy megb�zhatatlan program sz�m�ra, hogy r�vegye
   az ldd felhaszn�l�t mesters�ges k�d futtat�s�ra (ahelyett, hogy
   egyszer�en megmutatn� az ldd inform�ci�t). Teh�t a biztons�g kedv��rt
   ne haszn�ld az ldd-t olyan programra, amiben nem b�zol meg.
     _________________________________________________________________

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 [48]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. Dinamikusan bet�lthet� (Dynamically Loaded; DL) programk�nyvt�rak

Dinamikusan bet�lthet� (DL) programk�nyvt�rak olyan programk�nyvt�rak, amik
nem a program indul�sakor t�lt�dnek be. K�l�n�sen hasznos modulok �s
plug-in-ek megval�s�t�s�ra, mivel lehet�v� teszi, hogy csak akkor t�lts�k
be ezeket, ha sz�ks�ges. P�ld�ul a Bet�lthet� Hiteles�t� Modul (Pluggable
Authentication Modules; PAM) rendszer DL programk�nyvt�rakat haszn�l, �gy
lehet�v� teszi a rendszergazd�knak, hogy be�ll�ts�k �s �t�ll�ts�k az
hiteles�t�/azonos�t� elj�r�sokat. A dinamikusan bet�lthet�
programk�nyvt�rak j�l haszn�lhat�ak tov�bb� olyan �rtelmez�k
megval�s�t�s�ra, amik alkalmank�nt leford�tanak k�dokat g�pi k�dra �s a
leford�tott hat�kony v�ltozatokat haszn�lj�k, mindezt le�ll�s n�lk�l.
P�ld�ul ez az elj�r�s haszn�lhat� just-in-time ford�t�k vagy multi-user
dungeon (MUD) megval�s�t�s�ra.

Linuxon a DL programk�nyvt�rak jelenleg formailag semmilyen speci�lis
tulajdons�ggal nem rendelkeznek. Standard t�rgyk�dk�nt vagy megosztott
programk�nyvt�rk�nt k�sz�lnek, mint ahogy azt feljebb m�r bemutattuk. A f�
k�l�nbs�g, hogy ezek a programk�nyvt�rak nem t�lt�dnek be automatikusan a
program csatol�sa vagy elind�t�sa sor�n. Ehelyett van egy API, aminek
seg�ts�g�vel megnyithatjuk a programk�nyvt�rat, szimb�lumokat kereshet�nk
benne, jav�thatjuk a hib�kat �s bez�rhatjuk a programk�nyvt�rat. C
felhaszn�loknak a <dlfcn.h> header f�jlt kell beszerkeszteni (include) ennek
az API-nak a haszn�lat�hoz.

Az interf�sz haszn�lata Linuxon alapvet�en ugyanolyan mint Solaris-on, amit
"dlopen()" API-nak fogok h�vni. Ugyanakkor ezt az interf�szt nem t�mogatja
minden platform. HP-UX egy m�sik shl_load() mechanizmust haszn�l �s a
Windows platform is egy teljesen m�s DLL interf�szt haszn�l. Ha a c�lod a
sz�lesk�r� hordozhat�s�g, akkor val�sz�n�leg valamilyen k�ztes
programk�nyvt�rat kell haszn�lnod, ami elrejti a k�l�nbs�geket a platformok
k�z�tt. Egy megold�s lehet a glib programk�nyvt�r, ami t�mogatja a modulok
dinamikus bet�lt�s�t. Ez az platformok dinamikus bet�lt� rutinjait
haszn�lja ahhoz, hogy egy hordozhat� interf�szt val�s�tson meg ezekhez a
f�ggv�nyekhez. T�bbet tudhatsz meg a glib-r�l a
[49]http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.
html honlapon. Mivel a glib interf�sz j�l dokument�lt nem r�szletezem itt.
Egy m�sik lehet�s�g a libltdl haszn�lata, ami r�sze a [50]GNU libtool-nak.
Ha t�bbet akarsz enn�l, akkor vess egy pillant�st a CORBA Object Request
Broker (ORB)-re. Ha m�g mindig �rdekel, hogyan haszn�lhatod k�zvetlen�l a
Linux �s Solaris interf�szeket, akkor olvass tov�bb.

Azok a fejleszt�k aki C++-t �s dinamikusan bet�lthet� (DL)
programk�nyvt�rakat akarnak haszn�lni elolvashatj�k a "C++ dlopen
mini-HOGYANt".
     _________________________________________________________________

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.

   A dlopen()-ben a flag �rt�ke RTLD_LAZY "akkor oldja fel a nem
   defini�lt szimb�lumokat, amint egy k�d a dinamikus programk�nyvt�rb�l
   futtat�sra ker�l", vagy RTLD_NOW "felold minden nem defini�lt
   szimb�lumot, miel�tt a dlopen() visszat�r �s hib�t ad vissza, ha ez
   sikertelen volt". RTLD_GLOBAL opcion�lisan vagy kapcsolatban
   haszn�lhat� b�rmelyikkel a flag-ban, ami azt jelenti, hogy a
   programk�nyvt�rban defini�lt k�ls� (external) szimb�lumok el�rhet�ek
   lesznek a t�bbi bet�lt�tt programk�nyvt�rban is. Hibakeres�s k�zben
   val�sz�n�leg az RTLD_NOW-t akarod majd haszn�lni. Az RTLD_LAZY
   k�nnyen misztikus hib�kat okozhat, ha feloldhatatlan referenci�id
   vannak (unresolved references). Az RTLD_NOW eset�n kicsit tov�bb tart
   a programk�nyvt�r bet�lt�se (de felgyors�tja a keres�st k�s�bb). Ha
   ez felhaszn�l�i interf�sz probl�m�t okozna, akkor RTLD_LAZY-re
   v�lthatsz.

   Ha a programk�nyvt�rak f�ggnek egym�st�l (pl.: X f�gg Y-t�l), akkor
   el�sz�r a f�gg�s�geket kell bet�ltened (a p�ld�ban Y-t �s azt�n
   X-et).

   A dlopen() visszat�r�si �rt�ke egy "handle", amire �gy tekinthetsz,
   mint egy opaque �rt�k, amit m�s DL programk�nyvt�rak haszn�lhatnak. A
   dlopen() NULL-al fog visszat�rni, ha a bet�lt�s sikertelen volt. Ezt
   ellen�rizned is kell. Ha ugyanazt a programk�nyvt�rat t�bbsz�r t�lt�d
   be dlopen()-el, az ugyanazt az f�jlkezel�t (handle) fogja visszaadni.

   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 [51]"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 [52]"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. Egy�b

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 "-� 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 "inf� dokumentum�ban
   ([53]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.2.1. Speci�lis f�ggv�nyek, _init �s _fini (ELAVULT/VESZ�LYES)

T�rt�nelmileg l�tezik k�t speci�lis f�ggv�ny a _init �s a _fini, amik
lehet�v� teszik a konstruktorok �s a destruktor vez�rl�s�t. Ugyanakkor ezek
elavultak �s haszn�latuk megj�solhatatlan viselked�st eredm�nyezhet. A
programk�nyvt�raidban sz�ks�gtelen ezeket haszn�lnod. Helyett�k a fenti
f�ggv�ny argumentumokkal ell�tott konstruktor �s destruktor f�ggv�nyeket
haszn�ld.

Ha r�gi rendszeren kell dolgoznod, vagy olyan k�ddal ami haszn�lja a _init
vagy a _fini f�ggv�nyeket, akkor itt tal�lhat� a m�k�d�si le�r�suk. K�t
speci�lis f�ggv�nyt defini�ltak a modulok inicializ�l�s�ra �s a befejez�sre:
_init �s a _fini. Ha a programk�nyvt�rban nyilv�nos "_init" f�ggv�ny van
defini�lva, akkor az megh�v�dik, amikor a programk�nyvt�rat el�sz�r
megnyitjuk (dlopen()-el vagy egyszer�en megosztott programk�nyvt�rk�nt). C
programban ez egyszer�en azt jelenti, hogy defini�lsz egy f�ggv�nyt _init
n�vvel. L�tezik egy _fini nev� f�ggv�ny, ami megh�v�dik mindannyiszor, ha a
program befejezi a programk�nyvt�r haszn�lat�t. (dlclose() megh�v�s�val,
amikor az a referencia sz�ml�t 0-ra �ll�tja vagy a program norm�lis
kil�p�sekor). A C protot�pusok:

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

   Ebben az esetben, ha az t�rgyk�dot k�sz�t�nk (".�) gcc-vel a
   "-nostartfiles"opci�t meg kell adnunk. Ez meg�vja a C ford�t�t att�l,
   hogy a .so f�jljal szemben a rendszerind�t�si programk�nyvt�rakat
   satolja a programhoz. Ellenkez� esetben "multiple-definition"
   (t�bbsz�r�s defin�ci�) hib�t fogsz kapni. Megjegyez�nk, hogy ez
   teljesen elt�r att�l az esett�l, amikor modulokat a javasolt
   f�ggv�nyattrib�tumos megold�ssal ford�tasz. K�sz�net Jim Mischel-nek
   �s Tim Gentry-nek a javaslat�rt, hogy ker�lj�n ide egy le�r�s a _init
   �s _fini-r�l, �s hogy seg�tettek elk�sz�teni azt.
     _________________________________________________________________

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
[54]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 [55]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
[56]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 [57]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 [58]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
[59]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: [60]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. Tov�bbi p�ld�k

Az al�bbi p�ld�k mindh�rom programk�nyvt�r t�pussal foglalkoznak (statikus,
megosztott �s dinamikus programk�nyvt�rak). A libhello.c f�jl egy trivi�lis
programk�nyvt�r, a libhello.h header-rel. A demo_use.c f�jl egy trivi�lis
program, ami a programk�nyvt�rat haszn�lja. Ezt k�vetik a dokument�lt
szkriptek (script_static �s script_dynamic), amik bemutatj�k, hogyan
haszn�lhatod a programk�nyvt�rat megosztott illetve statikus
programk�nyvt�rk�nt. Ezut�n a demo_dynamic.c f�jljal �s a script_dynamic
szkripttel megmutatjuk, hogyan haszn�lhatod a megosztott programk�nyvt�rat,
mint dinamikusan bet�ltet� programk�nyvt�rat.
     _________________________________________________________________

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 "hell� 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 "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 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
     _________________________________________________________________

7. Tov�bbi inform�ci�

Tov�bbi hasznos inform�ci�kat tal�lsz a programk�nyvt�rakr�l a k�vetkez�
forr�sokban:

     * Daniel Barlow: "The GCC HOWT�. Ez a HOGYAN k�l�n�sen a ford�t�
       (compiler) kapcsol�kat t�rgyalja, amivel programk�nyvt�rakat
       k�sz�thet�nk. Olyan inform�ci�kat tartalmaz amivel itt nem
       foglalkoztunk �s viszont. A HOGYAN a Linux Documantation Project
       oldal�n kereszt�l �rhet� el: [61]http://www.tldp.org.
     * Tool Interface Standards (TIS) biztos�g: "Executable and Linkable
       Format (ELF)" (ez jelenleg egy fejezete a Portable Formats
       Specification Version 1.1.-nek ugyanett�l a bizotts�gt�l). Ez az
       ELF form�tumr�l tartalmaz nagy mennyis�g� �s r�szletes
       inform�ci�t (ami nem Linux vagy GNU gcc specifikus). L�sd:
       [62]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz Ha
       az MIT-r�l szeded le a f�jlt, akkor kicsomagol�s ut�n egy "hps"
       �llom�nyt fogsz kapni. Csak t�r�ld az els� �s utols� sort, majd
       nevezd �t "ps"-re �s egy nyomtathat� Postscript �llom�nyt kapsz a
       szok�sos f�jln�vvel.
     * Hongjui Lu: "ELF: From the Programmer's Perspective" . Linux �s
       GNU specifikus inform�ci�kat tartalmaz a ELF-r�l, a
       [63]ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
       webhelyen �rhet� el.
     * Az ld dokument�ci�ja: "Using LD, the GNU Linker" �rja le az ld-t
       messze a legr�szletesebben. 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