kernel headers, compilazione, glibc: un po di chiarezza

[Paoletta]

nstalla SIA il pacchetto headers 2.4.32 sia il pacchetto 2.6.14.3 poi rimuovo il pacchetto headers 2.6.14.3

a sto punto non bastava installare semplicemente gli headers del 2.4?

[meritil]

Ciao a tutti,
io quando aggiorno il kernel aggiorno anche gli headers...ma pare che questa sia sbagliato. Tuttavia non ho mai avuto problemi di compilazione causati dagli headers. Have a nice day

Si anch'io assolutamente aggiorno gli headers al kernel che uso.. mai avuto un problema, quello che dice stallman è senz'altro corretto ma puramente ipotetico( il cosiddetto caso pessimo), infatti è più probabile che si verifichi un incompatibilità tenendo gl'header del 2.4.32 usando codice oggetto del 2.6.x che viceversa.. senza contare poi le limitazioni che vi autoimponete usando headers pregressi. (niente di sensibile per un utente "comune" cmqe )


Ciao


ps: la soluzione di istallare il pacchetto 2.4.ecc-headers poi il 2.6.14-headers e infine disistallare quest'ultimo è assurda. ( ..non sono sicuro di aver capito bene i messaggi precedenti )

[sid77]

nstalla SIA il pacchetto headers 2.4.32 sia il pacchetto 2.6.14.3 poi rimuovo il pacchetto headers 2.6.14.3

a sto punto non bastava installare semplicemente gli headers del 2.4?

o i kernel headers 2.6
installando i 2.4, i 2.6 e rimuovendo i 2.6 si è ritrovato con un misto di headers 2.4/2.6 (che per fortuna funziona!) il messaggio: ".... was found in another package. Skipping. " non significa che il file non è cambiato, semplicemente che hanno lo stesso nome.

quindi adesso si ritrova con i file presenti in kernel headers 2.4 ma con il codice aggiornato alla 2.6 (brrrrr) ma, ripeto, per fortuna che gli fuiziona ancora tutto

[meritil]

( ..non sono sicuro di aver capito bene i messaggi precedenti )

allora avevo capito bene...

[samiel]

Tread molto interessante, ma dalle conclusioni non chiare.
Che sarebbe opportuno avere gli stessi header con cui
sono compilate le glibc,
lo rileva anche pjv. Alla prova dei fatti,
non converrebbe a questo punto installare gli header
del kernel che si usa, e ricompilare le glibc stesse?

M.

[sid77]

Alla prova dei fatti, non converrebbe a questo punto installare gli header
del kernel che si usa, e ricompilare le glibc stesse?

cioè compilare le glibc *OGNI* volta che cambi kernel?!? ma ma ma non ti sembra un pelo eccessivo? ricordati che per installarle devi bootare da cd, rimuovere le solibs vecchie e mettere quelle nuove...
ripeto: i file in /usr/include/... servono solo alle applicazioni, non al kernel, e il 90% delle app compila con i kernel headers 2.4, i kernel headers 2.6 servono solo a un numero limitato di applicazioni e credo che vadano installati solo se necessari.

ciao

[first]

Tread molto interessante, ma dalle conclusioni non chiare.
Che sarebbe opportuno avere gli stessi header con cui
sono compilate le glibc,
lo rileva anche pjv. Alla prova dei fatti,
non converrebbe a questo punto installare gli header
del kernel che si usa, e ricompilare le glibc stesse?

M.

non e' necessario ricompilare le glibc ad ogni cambio di kernel mi spiego meglio. SE io parto con glibc precompilate (tgz insomma) e poi mi decido a compilarmele da me perche voglio ottimizzarle per la mia macchina allora non ha nessuna importanza se cambio il kernel che uso, quelle glibc rimangono ottimizzate per la mia macchina e stop. Se ricompilo di nuovo le glibc (usando un nuovo kernel) ottengo i medesimi uguali spiaccicati "binari" glibc.

Samiel (ma sopratutto meritil) rifletti solo su questo fatto:
Patrick presumo che usi un kernel 2.4.32 sul suo pc. Cosi come credo che compili sul suo pc i vari pacchetti di slackware (anche quelli current spero!). Ti sei mai chiesto come mai certi pacchetti (come udev) che funzionano solo con kernel >2.6 FUNZIONANO pure sul mio(per esempio) pc che ha un kernel > 2.6 ? ? eppure LUI non ha i kernel-header del 2.6.

Questo esempio non e' mio. io ho solo rielaborato un esempio che fa torvalds (non stelmann lol) qui: http://uwsg.iu.edu/hypermail/linux/kern ... /0639.html


Raga volevo ribadire una cosa: io ho aperto questo 3ad solo per confrontarmi con voi e cercare di capire meglio come funziona la questione della compilazione insieme a voi, quello che scopro giorno dopo giorno lo riporto a voi chiedendo conferme perche io parto da 0 (ho solo dato anni fa instituzioni di informatica al poli). E' quindi ovvio che nei miei primi post (cosi come anche nei prossimi) ci sono cose magari smentite nei post successivi, questo perche e' tutto un workinprogress.


PS Samiel forse mi sbaglio io ma hai detto che tu usi un kernel che ti sei compilato da te. Quindi NON devi installare il pacchetto kernel-headers, i kernel Headers del tuo kernel compilato da te li hai dentro la directory in cui c'e' il sorgente!!

il pacchetto kernel-headers lo installi solo se installi un kernel precompilato e solo se hai intenzione di compilarti da te i programmi .

Il pacchetto kernel-2.6.xxxx contiene in pratica solo il bzImage...
I kernel-header sono tenuti separati proprio per questo (infatti li trovi nel ramo develop)

[samiel]

Beh, posto che - a differenza della biancheria intima -
non si cambia kernel ogni giorno (io l'ho ricompilato
anche svariate volte in alcuni casi, ma eccezionali e
solo per determinati problemi), se uno necessita davvero
di un kernel 2.6 o comunque valuta che (come a me pare)
per i desktop sia una scelta migliore del 2.4,
può sempre darsi alla ricompilazione delle glibc.
Dopo di che non ho capito se, in conclusione,
il popolo di slacky segue il consiglio di linus
o continua a usare gli header dei vari kernel nuovi che installa.
So che non è una questione di voto maggioritario,
ma mi piacerebbe capire l'orientamenteo...

M.

[first]

nstalla SIA il pacchetto headers 2.4.32 sia il pacchetto 2.6.14.3 poi rimuovo il pacchetto headers 2.6.14.3

a sto punto non bastava installare semplicemente gli headers del 2.4?

o i kernel headers 2.6
installando i 2.4, i 2.6 e rimuovendo i 2.6 si è ritrovato con un misto di headers 2.4/2.6 (che per fortuna funziona!) il messaggio: ".... was found in another package. Skipping. " non significa che il file non è cambiato, semplicemente che hanno lo stesso nome.

quindi adesso si ritrova con i file presenti in kernel headers 2.4 ma con il codice aggiornato alla 2.6 (brrrrr) ma, ripeto, per fortuna che gli fuiziona ancora tutto

Per paoletta: io ho fatto quello per provare una mia tesi....
Per sid: ovvio che funziona tutto! le glibc non servono per il normale uso desktop ossia non ce ne facciamo niente delle glibc se non compiliamo niente.....

[first]

installando i 2.4, i 2.6 e rimuovendo i 2.6 si è ritrovato con un misto di headers 2.4/2.6 (che per fortuna funziona!) il messaggio: ".... was found in another package. Skipping. " non significa che il file non è cambiato, semplicemente che hanno lo stesso nome.

Sid deciditi, anche perche io ho fatto questo esperimento seguendo le tue tesi.

first ha scritto:
Ho un dubbio ora: ma se io scarico i pacchetti tgz del kernel nuovo, i pacchetti degli headers del nuovo kernel vanno a sovrascriversi in /usr/include ?

assolutamente no!

[first]

Elimina i symlink e installa il tgz con gli headers.

Come faccio a vedere con quali kernel headers e' stato fatto il pacchetto tgz delle glibc presenti nel ramo current?

http://www.slackware.at/data/slackware- ... SlackBuild

Ue gallo ho letto quel slack.build e ho visto sta cosa

# Start with the linuxthreads version, as it's what is compiled against by default (until
# such time as 2.4.x kernels are no longer in use):
echo "BUILDING DAS LINUXTHREADS"
CFLAGS="-g $OPTIMIZ" \
../configure \
--prefix=/usr \
--enable-kernel=2.4.1 \
--with-headers=/usr/src/linux-${HEADERSTWOFOUR}/include \ <---------------
--enable-add-ons=libidn,linuxthreads \
--with-tls \
--without-__thread \
--without-cvs \
$TARGET-slackware-linux

${HEADERSTWOFOUR dobbiamo settarla noi per dirgli la versione del kernel con cui vogliamo che siano compilate.

Qui dovrebbe essere la chiave per risolvere i nostri dubbi..

[gallows]

Sì lo sapevo (tempo fa le avevo ricompilate), ma IMHO non ne vale la pena. Un sacco di tempo per compilare il tutto e le probabilità di fare casini sono alte

Per sid: ovvio che funziona tutto! le glibc non servono per il normale uso desktop ossia non ce ne facciamo niente delle glibc se non compiliamo niente.....

Eeeeeh??? Senza le glibc non puoi fare *nulla*

@Samiel:
Io seguirò i consigli di Pat e Linus, se mi serve compilare con gli header del kernel attuale cambio le flag a gcc.

[samiel]

@Samiel:
Io seguirò i consigli di Pat e Linus, se mi serve compilare con gli header del kernel attuale cambio le flag a gcc.

Per cui installi gli headers del 2.6, ma NON in /usr/src/
Ho capito bene?

M.

[gallows]

Io tengo in /usr/src una directory `linux' con i sorgenti del kernel in uso.
Se ad esempio un programma necessita degli header del 2.6 dico a gcc di usare gli altri header (che sono in una posizione non standard) es:

Codice: Seleziona tutto

% gcc foo.c -I/usr/src/linux/include

[meritil]

Secondo me bisogna chiarire un punto... di che macchina stiamo parlando? di un muletto dove facciamo le peggio prove istallando un nuovo kernel appena esce o una macchina che deve funzionare nel vero senso della parola?

Per esempio sul mio sacro pc mi sono fermato al 2.6.11.7 (mi sarei fermato prima ma per via del pci-x ho aggiornato) ... ho gl'headers del medesimo e compilo tutto con quelli.. (lasciamo perdere il fatto che non ho mai riscontrato problemi di incompatibilità) se un giorno però un eseguibile precompilato con 2.4 dovesse darmi noie ... lo ricompilo punto!

Inutile stare a farsi le p... mentali su una macchina dove si fanno prove e sperimentazioni varie.. non può esserci un compromesso tra sperimentazione e stabilità, è proprio per questo che la slack esce ancora con il 2.4 di default.. per motivi inerenti la stabilità.

La stabilità assoluta in senso di compatibilità, con il 2.6 in teoria si ha ricompilando praticamente TUTTO il software, ricompilare solo le glibc senza ricompilare il software che ne fa un uso stretto è erratissimo, ci si da la zappa sui piedi... (sempre teoricamente parlando) infatti questo è un punto sul quale i cugini di gentoo ci prendono (a ragione) fortemente per il c..o

..per concludere.. cosa si vuole dal SO? stabilità assoluta? o ci si tiene una release ben nota di slackware aggiornando solo i pacchetti inerenti ad essa.. o mettere un 2.6 e ricompilare tutto. secondo me se vogliamo fare i fiscali non c'è via di mezzo, nessun trucchetto insomma.



Ciao