Nefunkcni py-lxml

[Dan Lukes]

Miroslav Prýmek napsal/wrote, On 09/21/09 20:27:
>>> --> Vsiml jsem si, ze portupgrade vypisuje "Backing up the old version",
>>> ale nejak netusim, kde ji najit...

Tak to zhlavy nevim. Bud' ti poradi nekdo tady, nebo Google, nebo si 
vytvoreny balik anjdes findem.

> Je to treba tady: http://www.freebsd.org/doc/en/books/handbook/anoncvs.html

Tam to vypada, ze vycet "anoncvs" serveru je uplny a neprilis dlouhy. 
Jinak je ale stranka zastarala - uvadena "cena" za pouziti cvsup 
(nutnost instalace programu) jzi delsi dobu neplati. C varianta tohoto 
programu, csup, je soucasti zakladni instalace.

> Nicmene v tomhle jsme si nerozumeli - kdyz jsem psal "po kompilaci", tak 
> jsem tim myslel "kompilaci balicku"
> - kompilaci, linkovani, ...., instalaci. Takze spravne otazka mela znit 
> "jaktoze se balicek bez problemu prelozi
> a nainstaluje, kdyz mu chybi nejaky symbol v knihovne, kterou pouziva" - 


Tak zaprve - my se celou dobu bavime o problemu pri pouziti knihovny:

> ImportError: /usr/local/lib/python2.5/site-packages/lxml-2.2.1-py2.5-freebsd-7.2-RELEASE-i386.egg/lxml/etree.so: Undefined symbol "xsltProcessOneNode" 

Nas problem je, ze knihovna etree.so vyzaduje, aby nekdo z venku (v 
tomto pripade dokonce vime kdo - libxml knihovna) dodal implementaci 
symbolu a ona ho nedodava.

Jinak ale - moje vysvetleni bylo zjednodusene a ty se ptas an neco, co 
zjednoduseny vyklad nepostihl. Zaprve jsem zanedbal rozdil mezi 
statickymi a dynamickymi knihovnami (a linkovanim) a za druhe jsem 
nezminil, ze "linkovani" nemusi nutne probehnout v jednom kroku.

Zacnu tim druhym - muzes slinkovat dva objekty a ziskat objekt novy. Ten 
muze byt znovu predmetem linkovani pozdeji.

To prvni je slozitejsi. Kdyz jsem mluvil o finalnim spustitelnem 
programu tak ve skutecnosti ne kazdy program, ktery ti lezi na disku je 
v tomto stavu. Uvaz ze urcite funkce pouziva prakticky kazdy program. 
malloc(), printf(), exit(), ...

Kdyby byly vsechny programy ulozeny na disku v tim stavu, v jakem jsem 
zjednodusene popsal - to jest - u kazdeho symbolu by byla nakonec 
pripojena i implementace, byla by spousta kodu v naprosto identicke 
variante na disku mnoho a mnohokrat. To je jednak skoda mista na disku, 
druhak, totez by platilo i pri natazeni kodu programu do pameti pri 
spusteni. Co spusteny program, to pamet zabrana identickou implementaci 
funkce exit().

Ve lze jako spustitelny soubor na disk ulozit nedolinkovany "polotovar" 
s odkazem na (dynamicke) knihovny, ktere je treba dolinkovat, nez bude 
mozne kod spustit. To co lezi na disku jako spustitelny program tak 
jeste neni primo spustitelne - jeste to musi prijit poslednim 
(dynamickym) linkovanim, ktere se provadi v okamziku, kdy prijevis zajem 
program spustit. A tak vetsian programu v sobe exist() nema - jen 
nevyreseny symbol "exit". A k tomu informaci, ze k programu je treba 
pripojit libc. V te se implementace exit() nachazi. Pro vsechny takove 
polotovary je tak na disku implementace exit jen jednou - a co je jeste 
lepsi - jen jednou bude i v pameti bez ohledu na to, kolik programu 
pouzivajicich tuto funkci z dynamicke knihovny pobezi.

Ma to ale jeden negativni efekt - muze se stat, ze "polotovar" nepujde 
spustit. Staci aby libc chybela nebo byla poskozena. Nebo tam byla nova 
verze, ve ktere implementace exit() chybi.

To posledni popisuje pripad, ktery se stal tobe.

> No a me slo o to, ze nevim, jak vnitrne to linkovani presne funguje - 
> predpokladam,
> ze .so objekt ma v sobe nejaky zaznam "potrebuju objekty libprvni.so.1 a 
> libdruha.so.2"
> a pak ma seznam nedefinovanych symbolu, kterej se ale resi az tehdy, kdy 
> se symbol skutecne
> pouzije nebo co...

V podstate presne tak.

.so (shared object, sdilena nebo take dynamicka knihovna) je normalni 
objekt v tom smyslu, ze obsahuje seznam "toto exportuju pripadnym dalsim 
zajemcum" a "toto jsou moje nevyresene symboly". Navic (v porovnani se 
statickymi .o objekty) ma seznam dalsich dynamickych knihoven, ktere se 
automaticky pridaji do seznamu linkovanych objektu jakmile je pridana 
tato knihovna.


> Pomoci ldd potom muzu zjistit, jestli jsou k dispozici vsechny tyhle 
> objekty, 

Ano

> ale nezjistim, jestli
> jsou k dispozici skutecne vsechny symboly, ktery jsou nedefinovany...

Ano. To se zjisti jedine tak, ze nechas probehnout linkovani. navzdory 
tomu, ze jsem nahore napsl, ze finalni linkovani probiha az v ramci 
spusteni, i to bylo trochu zjednoduseni. Muzes zadat "pokusne slinkuj, 
ale vysledek nespusti" (man rdlt hledej LD_TRACE_LOADED_OBJECTS)


> # gcc -shared myapp.o -o libmyapp.so
> prestoze je tam ten nedefinovanej symbol myLibFunc (v knihovne je 
> myLibFuncX)

Jasne - vyrabis knihovnu. V te je normalni, ze existuji nezresolvene 
symboly.


> Porad nerozumim tomu, proc je mozny vytvorit knihovnu, ktera ma nejaky 
> nedefinovany symboly, ktery nejsou v dobe jejiho prekladu k dispozici v zadne z 
> knihoven, ktery linkuje

Asi to moje vysvetlovani neni tak dobre. Rikal jsem, ze kompilace je vec 
s linkovanim zcela nesouvisejici. Otazka "jake jsou symboly v knihovnach 
v okamziku kompilace" nema smysl.

Jinak je ale odpoved "a proc ne" ?

Jestli takovy vysledek nechces, tak ho nedelej. Okontrolovat, jestli to 
nastalo nebo ne, muzes, jestli se tak rozhodnes.

Jsou ale situace, kdy to tak muzes chtit. Nakonec - nevytvaris finalni 
produkt, ten se bude vytvaret az nekdy jindy (a mozna nekde uplne 
jinde). Tam nekde mozna vse potrebne k dispozici bude. Neni duvod ti 
branit abys tady a ted nesmel vytvorit "polotovar", ktery pak a tam 
uspesne pouzijes. Ze tady nemas knihovnu k dispozici ? A proc. 
Nepotrebujes ji - tady to spustet nechces. Tady kompilujes (a mozna 
provadis nektere dilci linkovaci kroky, ne vsak finalni sestaveni).



						Dan



P.S. Mam dojem, ze se zaciname dotykat hranice off-topis - a to navic z 
te spatne strany. Tohle co tu probirame jsou dost obecne veci, s FreeBSD 
souvisejici jen v tom smyslu, ze "tam je to taky tak". Trochu se obavam, 
ze se blizime tomu, kdy by to uz mohlo nekoho, pravem, obtezovat. Pokud 
si nekdo prave rika "konecne ho to napadlo" - neobavejte se v takovych 
pripadech postezovat si moderatorovi (mimo konferenci). Zajisti, aby se 
to nedelo. S takrka nulovou zpetnou vazbou je nekdy tezke odhadnout, co 
je zajimave/uzitecne a co nudne a obtezujici.