Článek se pravda jmenuje programování pod Linuxem, ale stejně bych upozornil, že dlopen() není právě portable. Existuje na Linuxu a *BSD (a Solarisu), což asi řadě lidí stačí, ale jinak se hodí použít nějaký wrapper, např. libltdl, na nějž snad ještě dojde řeč v části o libtoolu (a v Gtk+ programech používám z pohodlnosti GModule...). Krom toho na Linuxu lze samozřejmě používat nejen funkce dlopenutého programu (,modul`) dlopenujícím (,aplikace`), ale i naopak, což ovšem jinde nejde tak úplně samozřejmě...
S posledni vetou by se jiste dalo siroce polemizovat, ovsem myslim, ze to urcite neni obecny pripad. Zalezi hlavne, co za funkce (resp. symboly) to je, ale zejmena, jak je dana aplikace zkompilovana (-rdynamic, -Xlinker -E apod.). Jinak proste ty symboly v tabulce dynamickych symbolu nebudou a dlopen()nuty modul je nenajde.
Ovsem na druhou stranu je otazka, jestli modulu skutecne chceme zpristupnit plosne vsechny globalni symboly z aplikace...
OK, předpokládám-li normálně dynamicky slinkovaný program (což programy dlopenující jiné věci běžně bývají), potřebujete při linkování aplikace -Wl,--export-dynamic pro vyexportování všech dynamických symbolů, což nemusí každý považovat za ,samozřejmě`, ale ve srovnání s některými nejmenovanými platformami...
Jestli exportovat vše nebo ne ... IMHO jde hlavně o míru pokušení pro autory modulů, protože na to, aby dostali aplikaci do nekonzistentního stavu resp. rovnou crashli (vyvolali výjimky), mají dostatek prostředků i bez toho...
Spise jde o jejich disciplinu, aby pouzivali skutecne pouze definovana API a modul jim pak nefungoval pouze s jednou z deseti verzi programu. Vpodstate je to neco podobneho jako kontrola pristupu k ruznym casem objektu v nekterych OO jazycich (public/private).
K tomu by mohl postačovat hlavičkový soubor, kde jsou deklarovány funkce aplikace, které jsou public pro moduly (ten nejspíš stejně máte). Pokud se ho někdo nedrží, šťourá se ve zdrojácích aplikace a pak hrabe na bůhvíco dalšího, tak to už je IMHO jeho problém, protože mu musí být jasné, že to fungovat nebude.
Selektivní export je možné řešit vesrion-skriptem, ale to je celkem otrava...
Ahoj vsem,
hezky serial, ale mam jednu drobnou otazku. V minulem dile bylo uvedeno, ze pri linkovani programu "prilinkuju" k programu dynamickou knihovnu pomoci -lknihovna. Z dnesniho dilu jsem pochopil, ze i pri pouziti dlopen je toto nutne; knihovna se natahuje pri dlopen. Kdy se nahrava knihovna v tom prvnim pripade? A jak system vi (a od koho), ze "prilinkovana" knihovna pres -lknihovna nebude nahravana pres dlopen.
Diky.
Nikoliv, pokud otevirate knihovnu pres dlopen(), vas executable proti ni nelinkujete. Ovsem nemuzete samozrejme na druhou stranu primo pouzivat jeji symboly, ale "vytahovat" si je pres dlsym().
Zjednodusene to funguje zhruba tak, ze pri spusteni programu se ve skutecnosti spusti '/lib/ld.so prikazova radka'. /lib/ld.so je tzv. dynamicky linker, tedy prave program, ktery natahne vsechny potrebne dynamicke knihovny, proti kterym byl program slinkovan (pomoci -lknihovna).
V praxi se spousti spise /lib/ld-linux.so.2, a muzete si ho ostatne spustit i primo, vypise se vam takovy hezky help atd. ;-)
Asi by se to moc nehodilo do tohoto serialu, ovsem bylo by jiste zajimave sepsat nejaky podrobnejsi clanek o tipech, tricich a ruznych strategiich tykajicich se loadovani pluginu. Takovy plugin totiz obvykle potrebuje volat zpet neco v aplikaci, do ktere se zasouva, coz se ovsem da resit nekolika ruzne elegantnimi a ruzne portabilnimi zpusoby, od tabulky callbacku az po slepy export vsech symbolu k dispozici pluginum.
Mozna by se hodil kratky popis funkce strip,
plus informace o tom, proc mi nektere stripnute binarky (hlavne .a knihovny) nechteji fungovat, a jak udelat, abych je mohl stripnout a pritom aby fungovaly :)
ČLÁNKY DO MAILU