[RISOLTO] compilazione vlc

[d4z_c0nf]

A questo punto, come disablito la "creazione" degl'headers? Intendo come opzione del kernel.
rock

Il kernel gli header gli crea per forza, ma non devi installarli, tutto qui
Solo make e make modules_install

Sì sì, subito dopo averlo scritto ho editato conscio della ca****a che avevo detto.

grazie Conraid

[d4z_c0nf]

Dopo aver letto questi ultimi messaggi, mi si è fuso il cervello.

Fatemi capire bene: state parlando degli headers del kernel o di quelli delle LIBC?

Se io ricompilo un nuovo kernel, ad esempio, il 2.6.27, i sorgenti vengono messi in /usr/src/linux-2.6.27 e i relativi headers si vengono a trovare in /usr/src/linux-2.6.27/include.
Qualunque programma che, durante la compilazione, ha bisogno dei sorgenti del kernel (ad esempio, i driver nVidia, ndiswrapper, etc), va a cercare esclusivamente i sorgenti del kernel correntemente in uso; se non li trova genera un messaggio di errore.

Avete voglia di installare gli headers di Pat; se state usando un kernel 2.6.27, gli headers del 2.6.24.3 vengono ignorati!

A meno che io non abbia capito di cosa stiate parlando ...

E no phobos, gli headers vengono cercati in /usr/local/include e /usr/include/ , di default. Al massimo qualche programma può aver aggiunto qualche dir supplementare al path di inclusione delle intestazioni.
Infatti ora sto con il kernel 2.6.27.4 e con gli headers di Pat. Ovviamente gli headers, come diceva Conraid, del nuovo kernel ci sono e stanno in /usr/src/linux-2.6.27.4/include

[conraid]

Avete voglia di installare gli headers di Pat; se state usando un kernel 2.6.27, gli headers del 2.6.24.3 vengono ignorati!

A meno che io non abbia capito di cosa stiate parlando ...

Hai detto bene, alcuni programmi cercano gli header del kernel come dici tu, altri cercano in /include

Le "famose" parole di Pat, anche se erano per il cambio 2.4/2.6 erano queste

This package of 2.6.x based /usr/include/linux and /usr/include/asm headers
is being provided by request for some people who need it in order to compile
ASDL modem drivers for 2.6.x. As a general rule, installing kernel headers
that are newer than the kernel glibc was compiled with *may* cause problems,
so unless you need these for a particular reason it's best to stick with the
2.4.x kernel-headers package for now.

[d4z_c0nf]

Avete voglia di installare gli headers di Pat; se state usando un kernel 2.6.27, gli headers del 2.6.24.3 vengono ignorati!

A meno che io non abbia capito di cosa stiate parlando ...

Hai detto bene, alcuni programmi cercano gli header del kernel come dici tu, altri cercano in /include

Le "famose" parole di Pat, anche se erano per il cambio 2.4/2.6 erano queste

This package of 2.6.x based /usr/include/linux and /usr/include/asm headers
is being provided by request for some people who need it in order to compile
ASDL modem drivers for 2.6.x. As a general rule, installing kernel headers
that are newer than the kernel glibc was compiled with *may* cause problems,
so unless you need these for a particular reason it's best to stick with the
2.4.x kernel-headers package for now.

Sì sì le riconosco .
Taggato il topic come risolto.
Grazie ragazzi.

rock

[phobos3576]

Scusate ma, si stanno accavallando i vari messaggi. Vedo di rispondere ad entrambi.

E no phobos, gli headers vengono cercati in /usr/local/include e /usr/include/ , di default. Al massimo qualche programma può aver aggiunto qualche dir supplementare al path di inclusione delle intestazioni.
Infatti ora sto con il kernel 2.6.27.4 e con gli headers di Pat. Ovviamente gli headers, come diceva Conraid, del nuovo kernel ci sono e stanno in /usr/src/linux-2.6.27.4/include

In /usr/include e /usr/local/include vanno gli headers delle librerie come le LIBC, ALSA, CUPS, etc e non gli headers del kernel (a parte quelli del kernel originale di Pat)!

Gli headers del kernel sono rigorosamente quelli del kernel correntemente in uso; se hai installato i sorgenti, si trovano in /usr/src/linux-versione-kernel-in-uso/include.

Non puoi assolutamente usare i sorgenti di un kernel e gli headers di un altro kernel; otterresti una sfilza di errori.

Conraid, negli headers sono presenti le dichiarazioni di tipi e funzioni usate nelle librerie del kernel; se queste dichiarazioni non coincidono con le definizioni, esplode tutto!
Ad esempio, a partire dal 2.6.25, è stato stravolto tutto il supporto USB; se stai usando un 2.6.25, come puoi usare gli headers originali 2.6.24.3 di Pat?

[conraid]

Ad esempio, a partire dal 2.6.25, è stato stravolto tutto il supporto USB; se stai usando un 2.6.25, come puoi usare gli headers originali 2.6.24.3 di Pat?

Ti assicuro che lo faccio, compilo, e funziona tutto. Tranne i moduli che devono essere compilati naturalmente, ma quelli vanno a cercare gli header nei sorgenti del kernel
guarda il pacchetto kernel-headers e guarda dove installa gli header del kernel

Phobos, posso anche sbagliare, ma come ti dicevo ho sempre fatto così da quando mi compilo i kernel da solo, mai installati gli headers dei kernel se non tramite i pacchetti di Pat, eppure ho quasi sempre compilato i kernel per conto mio da vari anni

E come hai visto anche Rock installando in /usr/include gli headers del kernel compilato ha avuto errore, se ho capito bene
Come dici anche tu in /usr/include ci vanno gli headers del kernel compilato da Pat, ed io cosa ho detto? ma se installi gli header del kernel li ci finiscono i tuoi e non quelli di Pat... spero di essermi spiegato

[d4z_c0nf]

Scusate ma, si stanno accavallando i vari messaggi. Vedo di rispondere ad entrambi.

E no phobos, gli headers vengono cercati in /usr/local/include e /usr/include/ , di default. Al massimo qualche programma può aver aggiunto qualche dir supplementare al path di inclusione delle intestazioni.
Infatti ora sto con il kernel 2.6.27.4 e con gli headers di Pat. Ovviamente gli headers, come diceva Conraid, del nuovo kernel ci sono e stanno in /usr/src/linux-2.6.27.4/include

In /usr/include e /usr/local/include vanno gli headers delle librerie come le LIBC, ALSA, CUPS, etc e non gli headers del kernel (a parte quelli del kernel originale di Pat)!

Gli headers del kernel sono rigorosamente quelli del kernel correntemente in uso; se hai installato i sorgenti, si trovano in /usr/src/linux-versione-kernel-in-uso/include.

Non puoi assolutamente usare i sorgenti di un kernel e gli headers di un altro kernel; otterresti una sfilza di errori.

Conraid, negli headers sono presenti le dichiarazioni di tipi e funzioni usate nelle librerie del kernel; se queste dichiarazioni non coincidono con le definizioni, esplode tutto!
Ad esempio, a partire dal 2.6.25, è stato stravolto tutto il supporto USB; se stai usando un 2.6.25, come puoi usare gli headers originali 2.6.24.3 di Pat?

Scusami phob, pensavo ti riferissi agl'headers in generale, perciò ho detto che li cercava in quelle dir, invece ti riferivi agl'headers del kernel, quando un programma vuole usare files del kernel! Evidentemente vlc voleva degl'headers non del kernel, che purtroppo io avevo erroneamente sovrascritto con quelli del kernel.
Comunque scusami, ma quando compilo il kernel comunque vengono messi gli headers nella dir corrispondente. Semplicemente il mio pacchettizzatore li andava a mettere in usr/lib/include del pacchetto e quindi una volta installato succedeva il patatrac.
rock

[conraid]

[Semplicemente il mio pacchettizzatore li andava a mettere in usr/lib/include del pacchetto e quindi una volta installato succedeva il patatrac.
rock

succede anche senza pacchettizzare se li installi volontariamente.
mi sa che fra tutti si dice cose simili ma non ci capiamo

[phobos3576]

Credo che l'equivoco nasca dal fatto che d4z_c0nf sta usando (se ho capito bene) lo SlackBuild di Pat per pacchettizzare gli headers anche dei nuovi kernel; in quel caso, installpkg va ad installare gli headers in /usr/include/linux.

Se, invece, si usa il metodo generico, i sorgenti del kernel con i relativi headers vengono installati in /usr/src/linux-xyz.

EDIT: Ma Gohanz stava seguendo questa discussione?

E' appena apparso nel repository il package di LibV4l ...

[d4z_c0nf]

[Semplicemente il mio pacchettizzatore li andava a mettere in usr/lib/include del pacchetto e quindi una volta installato succedeva il patatrac.
rock

succede anche senza pacchettizzare se li installi volontariamente.
mi sa che fra tutti si dice cose simili ma non ci capiamo

Scusami, ti dicevo cosa faceva il mio "pacchettizzatore" perchè non da un

make headers_install

semplicemente si va a prendere tutti gli headers in /usr/src/linux-VERSION/include/

e li mette in pkgdir/usr/include

e poi crea il pacchetto.
Non so se sono riuscito a essere chiaro, obiettivamente prima avevo omesso questo "particolare"

@phobos3576
Non è lo sb di Pat, è un altro modificato. Non ricordo bene chi l'ha fatto, mi pare comunque uno di questa community

[conraid]

E' appena apparso nel repository il package di LibV4l ...

Ora servono anche a aMsn, che tra l'altro nelle ultime build mi da un errore in avvio

[d4z_c0nf]

E' appena apparso nel repository il package di LibV4l ...

Ora servono anche a aMsn, che tra l'altro nelle ultime build mi da un errore in avvio

Mah..aMsn l'ho tolto da un pezzo, troppo pesante.. O è migliorato?

[conraid]

E' appena apparso nel repository il package di LibV4l ...

Ora servono anche a aMsn, che tra l'altro nelle ultime build mi da un errore in avvio

Mah..aMsn l'ho tolto da un pezzo, troppo pesante.. O è migliorato?

Offtopic: Sulla pesantezza sempre uguale, anche se adesso stanno facendo amsn2, che sarebbe la convergenza tra gli sviluppatori di amsn e emesene

[d4z_c0nf]

Offtopic: Sulla pesantezza sempre uguale, anche se adesso stanno facendo amsn2, che sarebbe la convergenza tra gli sviluppatori di amsn e emesene

Eddai conraid ormai sto topic è morto, andare offtopic è lecito
Ecco perchè lo sviluppo di emesene (che uso) è abbastanza fermo.
rock

[conraid]

Offtopic: Sulla pesantezza sempre uguale, anche se adesso stanno facendo amsn2, che sarebbe la convergenza tra gli sviluppatori di amsn e emesene

Eddai conraid ormai sto topic è morto, andare offtopic è lecito
Ecco perchè lo sviluppo di emesene (che uso) è abbastanza fermo.
rock

http://www.amsn-project.net/forums/viewtopic.php?t=5299