Re: lug-bg: glibc 2.2.4

[danchev@xxxxxxxxx (George Danchev)]

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