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.
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
