On Wednesday 09 January 2002 09:50, you wrote: > George Danchev wrote: > ........ > > > 3. Vyobste ot tekustoto kernel source trqbva da se include-va samo ako se > > kompilirat kernel modules (ot source na samoto qdro ili vunshni kato > > NVdriver, etc...). Za vsi4ko sto ba4ka v user-space si ima libc si, > > Tova me ozadachava. Ili 3. ne e (napqlno) verno, ili > ne sqm v chas. > > Kompilaciyata, za koyato govorish, vklyuchva li i tazi > na glibc? Samata libc *e* userspace. Zashto togava tya > se vliyae izobshto ot linux i asm direktoriite? V > smisql, ako nito edin file na sorsa na glibc nyama > #include <linux/alabala.h> // priznavam, ne sqm chel i 1 red ot > sorsovete na glibc bi bilo napqlno bez znachenie ...
ne e nuzhno da 4etesh sources na bibliotekata ili kernela (ti da ne mislish 4e az gi 4eta ;), trqbva da se znae 4e ne trqbva da se mixirat po tozi na4in kato v slu4aq s symlinkovete - includes ot bibliotekata da so4at kym includes ot tekustoto kernel dyrvo ... - stoto razlika ima i ako nqma vinagi mozhe da se poqvi pri update na kernel dyrvoto, e sega kakvo za da sme safe vseki pyt kato smenim kernel source da prekompilirame i bibliotekata li , ste polu4im nqkolko novi definitions/includes, ama kolko hora ste gi polzvat ... vsutnost ako nqkoj tolko iska novite definitions/includes ot poslednoto kernel source za da gi polzva v source na svoeto user-space prilozhenie (koeto ne vinagi ste my dojde syvsem nagotovo de, stoto pove4eto ot tqh adresirat tipi4no kernelski nesta, ama neise ... ) ami vinagi mozhe da si gi get-ne po 100 na4ina ukazvajki na gcc -I /path/to/whatever/you/want.h i t.n., ama vyprosa e da go napravi po sane & safe na4in ... da si slozhi tozi .h v source-to na svoeto prilozhenie i da go vmukne ot tam (a ne da raz4ita 4e edi koq si versiq na kernel sourceto ste e nalice v sistemata) #include "alabala.h" kef my da exportne MYHEADERSPATH=/bla/bla/bla i posle gcc -I $MYHEADERSPATH i t.n. ... (ili napravi zadava -I /path/....) kef my ot sandartnite za tova mesta #include <bla/bla.h> (ste vklu4i /usr/include/bla/bla.h) kernel source se obnovqva mnogo po 4esto i imajki tezi symlinks ti fakti4eski obnovqvash kernel headerite i v bibliotekata (a posle linkvash programite kym shared objects kompilirani s starite includes koito sa bili v bibliotekata), a tova ve4e vodi do problema ilustriran v primera na Linus Torvalds... (ne e nuzhno da si developer 4e da go predotvratish ... to e qsno 4e v bibliotekata trqbva .h da matchvat shared objects v neq, ina4e tazi biblioteke e broken ot gledna to4ka na prilozheniqta ..., tova vazhi ne samo za kernel headers v neq a i za vsi4ki drugi headers v neq). Neka developerite na glibc da reshavat koj headers ot kernela ste vlizat v neq ... > glibc ne vklyuchva kernel moduli. estestveno :) Kogato se kompilira kernel space kod . Vizh Makefile-a na kernela ... toj polzva samo .h ot svoeto dyrvo , vizh kak go pravi ... Sustoto e i za kernel modulite, pri kompilaciqta im te includevat ot tekustoto kernel tree, taka vsi4ko ste e OK. Vsustnost C e bibliote4en ezik, vsi4ko interesno e v bibliotekite ... i mnogo 4esto sreshtani greshki sa vklu4vaneto na ne tova koeto trebe ... az neznam dali mozhah da se izqsnq..., mozhe bi nqkoj s pove4e dar slovo ste izbistri sitation-a. A btw v nikoj uvazhavashta sebe si syvremenna distribuciq nama da sreshnesh symliks ot /usr/include kym kernel tree-to. Taka e sigurno 4e nqma da imash problem s applicacijte si nezavisimo kakvi promeni ste napravqt kernel developerite v tehnite .h v sledvashtiq kernel release. (e po4ti de;) -- Greets, fr33zb1 =========================================================================== A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers) http://www.linux-bulgaria.org/ Hosted by Internet Group Ltd. - Stara Zagora
