kernel headers, compilazione, glibc: un po di chiarezza

[meritil]

o mettere un 2.6 e ricompilare tutto.

Errata Corrige:

...o mettere un 2.6, o un 2.4 diverso, e ricompilare tutto.

[first]

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*

Ho scritto glibc per errore, intendevo kernel header.

[first]

A raga' ma nessuno tra noi riesce a "togliere le pieghe" a sto problema "complicato"?

Ma possibile che Samiel, per esempio, installa i pacchetti tgz dei kernel-header quando si e compilato il kernel????

Quasi mi vergono a postare qui un link di gentoo (Genone e' uno sviluppatore di gentoo)
http://forums.gentoo.org/viewtopic-t-38 ... aders.html
Per la cronaca, nemmeno loro hanno le idee molto chiare su questo argomento..

Io mi sono affezionato a slackware non chiedetemi il perche'... ma e' stata la mia prima distro di linux e non la voglio cambiare. Quindi cerchiamo di dare una risposta che crei conoscienza noi di slacky.it.

[salbutamolo]

Ciao a tutti,

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

Molto vero

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

Non è vero che devi bootare da cd, basta effettuare l'aggiornamento in telinit 1, cosa che regolarmente faccio quando vengono rilasciate le glibc nuove del ramo current.

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

E' vero che il 90% delle applicazioni compila con gli headers 2.4 ma compilano perfettamente anche con gli headers 2.6, quindi se uso un kernel 2.6.x uso i suoi headers....non lo so mi sembra più logico. Have a nice day

[first]

Saltumbolo ma non capisco...
Io credo che torvalds ne sappia piu di tutti su cosa e meglio fare usando il SUO kernel, se lui scrive (e te lo traduco pure pero' cerca di leggere prima di rispondere se no non ha senso continuare sto 3ad).

Put another way that maybe is a clearer example:
If I hear that the new feature 2.3.5 of package
"foo" supports the new filesystem layout that I've been waiting for,
should I have to pray that the person who compiled the binary happened to
use one of the development kernels where that feature was actually
implemented?


Or should I have to recompile it myself to make sure?


Or, wonder of wonders, should it just WORK?


I think the latter. And I hope I've made clear to everybody why a software
package must NOT EVER depend on what kernel version happened to be
installed when it was compiled. And why it is so _important_ that nobody
even by mistake does this. EVER.

Traduzione:

Se sento che un nuovo pacchetto foo-2.3.5 supporta una nuova funzionalita (di un nuovo kernel 2.3.5) nel gestire il filesystem che stavo aspettando, dovrei pregare che la persona che ha compilato ( e quindi preparato per es. un tgz) lo abbia fatto su una macchina che utilizza il nuovo kernel nel quale quella funzionalita e' implementata?

O dovrei compilarmelo da me per essere sicuro?

O , MAGIA , dovrebbe gia semplicemente funzionare (anche sul mio pc che usa il nuovo kernel e quindi la nuova funzionalita')?

Io credo che la risposta giusta sia la seconda, e spero di aver fatto chiarezza sul PERCHE un pacchetto precompilato (tipo tgz) NON DEVE MAI dipendere dal tipo di kernel che e' installato (nel senso utilizzato) e col quale si e' compilato il pacchetto (tgz). E sul perche' e' importante che nessuno , anche per errore, faccia cosi. MAI

Linus dixit

[meritil]

@first:

Prima cosa il kernel non è di Torvalds e si sospetta non lo sia mai stato nemmeno nella prima bozza.. ma questa è solo una precisazone quindi lasciamo cadere per evitare flames

secondo poi le disquisizioni che leggi dai guru dei SO, come torvalds o stallman, devi prenderle in considerazione ma anche inquadrarle in un contesto necessariamente accademico e puramente fuori dal contesto reale, contensto che differisce di molto dalla realtà di "casa nostra", non è che torvalds sta incastrato sul Pc a creare link a include/asm e poi telefona a stallman per dirgli che le glibc gli vanno da paura...
con questo non voglio dire che torvalds dice cazz.. , per carità, però certe esclamazioni vanno inquadrate per bene prima di applicarle all'atto pratico solo per FEDE

terzo, il brano che hai citato non centra nulla con gl'header e su come è meglio agire.. cioè se istallare quelli con cui hai compilato le glibc oppure no..
dice giustamente che NON TUTTO il software precompilato dipende dal kernel con cui è stato generato.. (chiaramente e ovviamente) e implicitamente conferma che conviene utilizzare gl'header del kernel in uso per compilare software che avrà come target il kernel in questione...


Ciao

[salbutamolo]

e te lo traduco pure pero' cerca di leggere prima di rispondere se no non ha senso continuare sto 3ad

Ma tante grazie per la traduzione, non avrei saputo come fare altrimenti. Tu comportati come meglio credi, che io, ovviamente farò lo stesso, ma ti suggerisco di cambiare tono, e mi riferisco a:

pero' cerca di leggere prima di rispondere

Have a nice day

[first]

per merit e santu e per chi la pensa come loro:

Se mettete in discussione pure quello che dice linus, che vi devo dire, avete vinto voi.


PS il brano che vi ho tradotto ( e che vi avevo gia linkato la fonte in un mio precedete post) lo trovate qui:
http://uwsg.iu.edu/hypermail/linux/kern ... /0639.html

Ed e' in rispota alle molte obiezioni (come quelle di santu e merit) riguardo al suo primo post sul non linkare i kernel header in usr /include......

Per santu again (ancora):

Io in questo 3ad non sto chiedendo cosa volete fare VOI (per me voi potete fare quello che vi pare, che me frega!), ma sto chiedendo se qualcuno mi puo' spiegare meglio la frase di linus sul NON linkare i kernel header in /usr/include

E se ti dico di leggere prima di rispondere e' proprio per questo fatto!

Se vuoi "illuminarmi" su cosa santumbolo ha in (usr/include) apriti un tuo post dal titolo "io santumbolo che ne so piu di linus faccio cosi" ma non rispondere al mio perche sarebbe off topic

E sara pure che Linus non capisce niente di kernel, ma sta di fatto che sul README di qualsiasi kernel c'e' scritto NON (ed e' MAIUSCOLO) NON compilare un nuovo kernel in /usr/src/linux.

[gallows]

L'avviso che hai tradotto a salbutamolo mi sembra dedicato agli sviluppatori.. qui parliamo d'altro

Se vuoi un parere, la mia scelta dovrebbe essere abbastanza versatile.. ma comunque ripeto: ho usato gli stessi header del kernel in uso per un annetto scarso e non sono mai incappato in problemi.

Ps. Ti pregherei di moderare i toni.

[first]

Gallo il fatto e' che quando discuto con una persona che nega pure l'evidenza mi saltano i nervi.

cose devi rispondere a persone che ti dicono:
"Prima cosa il kernel non è di Torvalds e si sospetta non lo sia mai stato nemmeno nella prima bozza.. ma questa è solo una precisazone quindi lasciamo cadere per evitare flames"

e non mi sembra nemmeno offensivo richiedere di leggere (i miei post ma sopratutto i post di linus) prima di rispondere.
Perche se io chiedo spiegazioni sui post di linus e tu mi rispondi con strategie che sono CONTRO quello che dice linus, permettimi di rispondere che le sue repliche qui sono da considerare off topic.

e l?avviso che ho tradotto non e' dedicato agli sviluppatori, ho precisato che e' una risposta a una critica a chi sosteneva che bisognava linkare gli header del kernel che si utilizza (e che non e stato usato in sede di compilazione delle glibc) in usr/include.

Gallo se qualcuno ha dubbi basta che apre un link di linus che ho dato e sotto clicchi order author e poi si prende tutti i post inerenti al problema /usr/include e header kernl scritti da linus stesso.

[meritil]

@first

1) "Prima cosa il kernel non è di Torvalds e si sospetta non lo sia mai stato nemmeno nella prima bozza.. ma questa è solo una precisazone quindi lasciamo cadere per evitare flames"

Perchè vorresti assurdamente sostenere il contrario? http://www.kernel.org per i ragguagli...

2) Metto in dubbio quello che dice Linus Torvalds? ci mancherebbe che non lo facessi.. per la mia umile e misera conoscenza lo faccio e fortunatamente lo hanno fatto un sacco di altre persone che lavorano senza bramare le luci della ribalta... ehehe ma chi è Dio? (se lo fosse metterei in dubbio cmqe :P )

3) Secondo me il topic che hai quotato, che sottoscrivo anche perchè mi/ci da ragione, l'hai preso per il verso sbagliato..

4) Non ti arrabbiare non c'è bisogno, tra l'altro mi fai innervosire il buon Salbutamolo che mi sembra l'ultimo dei rissosi o degli incompetenti... cmqe pensiamo alla salute per me gl'headers li puoi istallare benissimo in /opt/firefox/bin se ti va... puoi venerare chi vuoi o prendere per buona qualsiasi cosa detta da chi più ti pare.. io personalmente non prendo mai nulla per buono.


Ciao


ps: oltre alle pizzicate ci sono anche argomenti interessanti nei thread precedenti non ti fossilizzare solo sulle prime dai...

[masalapianta]

Ciaa a tutti ho deciso di aprire questo post per capire meglio il problema degli headers.
...
Linus dice di NON creare quei symlink e di non compilare mai il nuovo kernel in /usr/src/linux (qui per leggere il suo commento http://uwsg.iu.edu/hypermail/linux/kern ... /0587.html ).

Da quel poco che ho capito io le glibc dovrebbero arrivare con i loro headers e quelli devono rimanere li, immobili, fissi per sempre, almeno finche non si aggiornano le glibc. E questi headers devono essere indipendenti dal kernel che si utilizza.
Gli headers del kernel invece devono essere utilizzati unicamente se si vuole compilare parti del kernel stesso.

questo e' ovvio, con un po di buon senso si dovrebbe capire che se hai installato sul sistema una versione xy delle glibc non e' una cosa saggia avere le librerie di sviluppo relative ad un'altra versione; perche'? ma perche' quando tu vai a compilare un software che viene linkato contro le glibc, il compilatore si va a vedere i prototipi delle funzioni negli headers (le librerie di sviluppo) e poi quando il linker va a cercare il codice oggetto nelle librerie ti puoi ritrovare con dei bellissimi unresolved symbol dovuti al fatto che magari le librerie di sviluppo (di una versione piu' recente rispetto a quella che hai) ti danno il prototipo di una funzione con argomenti e risultati differenti rispetto a come e' realmente nella libreria che hai tu (piu' vecchia), oppure la funzione in questione proprio non esiste nella versione xy (ma magari esiste nella versione xz relativa alle librerie di sviluppo che hai tu)

Quindi se io voglio un nuovo kernel NON devo andare a mettere i SUOI header in /usr/include.

certo che non devi, perche' come avrai ormai capito, andando a compilare dei software che linkano contro le glibc il compilatore si ritroverebbe con dei prototipi di funzioni che non necessariamente coinciderebbero con il codice oggetto che tu effettivamente hai nelle glibc

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 ?

boooo non uso slackware da almeno 7 anni, fai un aprova a verifica

P.S. ovviamente questo non vale solo per le glibc, non e' mai buona cosa avere sul sistema le librerie di una versione e le relative librerie di sviluppo di un'altra versione (sempre per il motivo di cui sopra)

[masalapianta]

Io in questo 3ad non sto chiedendo cosa volete fare VOI (per me voi potete fare quello che vi pare, che me frega!), ma sto chiedendo se qualcuno mi puo' spiegare meglio la frase di linus sul NON linkare i kernel header in /usr/include

E se ti dico di leggere prima di rispondere e' proprio per questo fatto!

non ho letto quel link ma presumo che Torvalds dicesse piu' o meno quel che ti ho detto io, in quanto e' l'unica motivazione sensata per cui e' male avere una libreria di sviluppo di una versione diversa rispetto alla libreria che hai installata sul sistema (e questo come ti ho gia spiegato vale a prescindere dalla libreria, quindi non solo per le glibc)

[first]

E' questo il tuo difetto: non leggi prima di rispondere...

le tu spiegazioni in merito agli header parafrasano alla lettera quello che dice torvalds, apprezzo lo sforzo ma, proprio per questo, non aggiungono niente a quanto gia sapevo.

Se leggessi _tutto_ il post capiresti che il mio problema e' capire come funziona slack con gli headers-kernel e sul perche alcuni ritengano necessario aggiornare il pacchetto degli header da 2.4 a 2.6 se installano un nuovo kernel 2.6.

[Paoletta]

ok gente...
sono stata lontano dal forum per qualche giorno e mi sono letta tutto il post..a parte il fatto che anche io seguirò quel che dicono Linus e masalapianta (per quel che ve ne può fregare), per rilassare gli animi di tutti io dico che c'è un'unica entità al mondo a cui si può andare a chiedere per risolvere tutti questi problemi (e magari il kernel è SOLO opera sua);
è questa!!!
detto questo, andate in pace...