[RISOLTO] compilazione vlc

[d4z_c0nf]

mi rimane il no per:

Codice: Seleziona tutto

checking for LIBV4L2... no
configure: WARNING: LibV4L2 support disabled because libv4l2 development headers
 were not found

Quel WARNING lo ottengo anche io ma non pregiudica il risultato finale della compilazione.
Ho notato che il configure prevede anche l'opzione:

Codice: Seleziona tutto

--with-v4l2=PATH       path to a v4l2-enabled kernel tree

Ho provato con tutte le directory possibili e immaginabili ma senza risultato.

Idem, ma vabè tanto non è quello il problema.

[d4z_c0nf]

Vabè non ne esco. Ci rinuncio.
Grazie a tutti.
rock

[pinguinosn]

la versione compilata su slacky va benissimo se necessiti di compilazione ad hoc
controlla bene i flag di compilazione e le relative dipendenze.

nb
non penso di essere l'utente fortunato.

[d4z_c0nf]

la versione compilata su slacky va benissimo se necessiti di compilazione ad hoc
controlla bene i flag di compilazione e le relative dipendenze.

nb
non penso di essere l'utente fortunato.

Non ho capito, tu hai compilato vlc con lo slackbuild di slacky, o stai usando il pacchetto di slacky?
Per la seconda, il pacchetto di slacky mi funziona, se ci metto anche tutte le dipendenze di slacky, ma io ho compilato anche le dipendenze, e il pacchetto di slacky non funziona sulle mie dipendenze in quanto alcuni pacchetti da me compilati sono più recenti e quindi c'è un mismatch sulle librerie condivise.

rock

[conraid]

la versione compilata su slacky va benissimo se necessiti di compilazione ad hoc
controlla bene i flag di compilazione e le relative dipendenze.

nb
non penso di essere l'utente fortunato.

Non ho capito, tu hai compilato vlc con lo slackbuild di slacky, o stai usando il pacchetto di slacky?
Per la seconda, il pacchetto di slacky mi funziona, se ci metto anche tutte le dipendenze di slacky, ma io ho compilato anche le dipendenze, e il pacchetto di slacky non funziona sulle mie dipendenze in quanto alcuni pacchetti da me compilati sono più recenti e quindi c'è un mismatch sulle librerie condivise.

rock

Ma se fai le cose in grande?
Cioè se parti da qui http://www.slackware.com/~alien/slackbu ... est/build/ ?

Naturalmente modifichi ARCH e versione delle varie librerie se vuoi, ma ti fa un pacchetto statico.
Lo puoi usare per vedere dove sta l'inghippo con il tuo

[d4z_c0nf]

la versione compilata su slacky va benissimo se necessiti di compilazione ad hoc
controlla bene i flag di compilazione e le relative dipendenze.

nb
non penso di essere l'utente fortunato.

Non ho capito, tu hai compilato vlc con lo slackbuild di slacky, o stai usando il pacchetto di slacky?
Per la seconda, il pacchetto di slacky mi funziona, se ci metto anche tutte le dipendenze di slacky, ma io ho compilato anche le dipendenze, e il pacchetto di slacky non funziona sulle mie dipendenze in quanto alcuni pacchetti da me compilati sono più recenti e quindi c'è un mismatch sulle librerie condivise.

rock

Ma se fai le cose in grande?
Cioè se parti da qui http://www.slackware.com/~alien/slackbu ... est/build/ ?

Naturalmente modifichi ARCH e versione delle varie librerie se vuoi, ma ti fa un pacchetto statico.
Lo puoi usare per vedere dove sta l'inghippo con il tuo

Sì ci avevo pensato, avevo visitato già lo slack di alien, il fatto della staticità mi ha frenato anche perchè io le dipendenze le ho già compilate e non saprei come modificare quello slackbuid. E poi non credo che siano le dipendenze il problema. Ho scaricato il tarrone(delle dipendenze) da slacky e ho provato a compilare vlc su quelle dipendenze installate, e comunque mi da quel problema con gli headers.

Poi perchè dici "in grande"?

rock

[conraid]

Poi perchè dici "in grande"?

Perché compila tutte le dipendenze al volo

Come ti ho già scritto, ma hai provato con il kernel e headers di default?

[phobos3576]

Strano che VLC, durante la compilazione, vada a cercare nei sorgenti del kernel.
Se HAL e DBUS sono abilitati, VLC non dovrebbe ficcare il naso nel kernel; altrimenti, a che serve un Hardware Abstraction Layer?

[conraid]

Strano che VLC, durante la compilazione, vada a cercare nei sorgenti del kernel.
Se HAL e DBUS sono abilitati, VLC non dovrebbe ficcare il naso nel kernel; altrimenti, a che serve un Hardware Abstraction Layer?

Ma perché sorgenti del kernel?
Non è che cerca gli header e basta (/include, e c'è qualche casino in quelli)
Anche quella voce V4L sembrano quasi le libv4l, e non la parte v4l del kernel, quella che usano i driver gspca per esempio.
il tutto imho e da ignorante

[d4z_c0nf]

Strano che VLC, durante la compilazione, vada a cercare nei sorgenti del kernel.
Se HAL e DBUS sono abilitati, VLC non dovrebbe ficcare il naso nel kernel; altrimenti, a che serve un Hardware Abstraction Layer?

RISOLTO:
Cerco di essere il più comprensibile possibile.

Premessa:utilizzo uno script per pacchettizzare il kernel.

La prima volta che ho compilato vlc, l'ho fatto con gli headers del nuovo kernel (2.6.27.4), pacchettizzati con lo script di cui sopra e installati.
Successivamente pensando che potessero essere quelli il problema, li ho disinstallati e ho reinstallato gli headers originali.
Niente da fare, in più mi dava quell'errore perchè cercava un file scsi_cmnd.h, invocato da scsi.n, che non c'era. Dopo aver reinstallato gli headers nuovi e dopo aver tentato diverse compilazioni mi sono chiesto, ma come mai questo file scsi.h cerca un file che non esiste?
La risposta è che il file scsi.h e scsi_cmnd.h (in /usr/include/scsi/) non è contenuto nel pacchetto degl'headers originali e così nemmeno il file scsi.h.
A questo punto do un bel

Codice: Seleziona tutto

grep -il "usr/linux/scsi/scsi.h" /var/log/packages/*

per vedere di chi è questo file, e perchè cerca un file che non esiste.
Ne viene fuori che è un file del pacchetto glibc-2.7-i486-10 e ovviamente nei nuovi headers.
Allora li "ri-rimuovo".
Quindi cosa è successo, installando gli headers nuovi quel file è stato sovrascritto!! Nella rimozione del pacchetto evidentemente non è stato rimosso perchè appartenente ad un altro pacchetto (glibc appunto), anche se ovviamente sono due file "diversi". Perciò non aveva funzionato la compilazione con gli headers vecchi, perchè pur avendo rimosso quelli nuovi il file scsi.h era rimasto inalterato e cercava un file che non c'era più.
Quindi ho reinstallato le glibc e mi sono tenuto gli headers vecchi.
E ora è tutto apposto.

Ora voglio capire se il problema è dello script che uso per pacchettizzare il kernel, o se comunque quei files (headers) vengono sempre installati (copiati) durante la compilazione, e il pacchettizzatore non fa altro che ricavarne dei pacchetti per poter tenere traccia dei files installati.
Se l'ipotesi è la prima vedrò di aggiustarlo.
Se è la seconda, mette paura a compilare un nuovo kernel, altrimenti, se non sbaglio, ci deve essere qualche opzione nel kernel per non fargli installare nuovi headers.

Grazie ragazzi, e scusate se vi ho fatto perdere tempo su un problema causato da me!
rock

[conraid]

io Rock seguo sempre il consiglio di Pat di usare gli headers con i quali sono state compilate le glibc, non metto mai gli headers dell'ultimo kernel che compilo. Se ne ho bisogno ricompilo anche le glibc, ma al 99% delle volte per glibc e headers mi tengo i pacchetti di Pat

Un kernel non installa *mai* nuovi headers se non glielo fai fare espressamente

Codice: Seleziona tutto

make 
make modules_install

non ti serve altro, il resto sono 3 file da copiare in /boot

[d4z_c0nf]

io Rock seguo sempre il consiglio di Pat di usare gli headers con i quali sono state compilate le glibc, non metto mai gli headers dell'ultimo kernel che compilo. Se ne ho bisogno ricompilo anche le glibc, ma al 99% delle volte per glibc e headers mi tengo i pacchetti di Pat

Sì infatti, lo so è un consiglio che dai spesso, e una volta linkasti anche qualcosa scritto da Pat. Solo che sai non avevo mai avuto problemi, e poi pensavo, se gli headers raccolgono i "prototipi" di funzioni c, se quei file c (del kernel) cambiano e hanno le stesse funzioni ma con un prototipo diverso, se non metto gli headers corrispondenti succede un casino. Capito, io pensavo proprio che potesse accadere il contario, headers vecchi e files.c nuovi mismatch assicurato.

Ok, ho tolto la pacchettizzazione degl'headers dallo script.
Se ho capito bene gli headers del kernel stanno in : /usr/src/linux-version/include/asm
rock

[conraid]

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

[conraid]

Ok, ho tolto la pacchettizzazione degl'headers dallo script.
Se ho capito bene gli headers del kernel stanno in : /usr/src/linux-version/include/asm
rock

Stanno in /usr/src/linux-version/include
non sono in asm

ma non devi installarli, tutto qui

alcuni programmi, come driver che creano moduli, tanto vanno a cercarli li, quindi ecco perché se vuoi compilare moduli extra non devi cancellare i sorgenti compilati, ma i normali programmi li cercano in /usr/include e li IMHO è bene che ci stiano quelli con cui sono state compilate le glibc


scusa la ripetizione

[phobos3576]

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 ...