Che cos'è la compilazione? Come si compila?

[MsZ]

Che cos'è la compilazione?

La compilazione è un procedimento informatico per il quale un linguaggio di programmazione, più o meno comprensibile agli esseri umani, quale può essere assembler, C, C++, FORTRAN o COBOL viene "tradotto" in un linguaggio o, per meglio dire, una serie di istruzioni comprensibili ad una macchina logica quale un PC od un supercomputer. I programmi che fanno questo vengono chiamati compilatori. Ovviamente esistono più tipi di compilatori, uno per ogni linguaggio di programmazione, che, essenzialmente, traducono in codice macchina le istruzioni del rispettivo linguaggio.
Il nome 'compilazione' deriva già dai tardi anni 40, quando le enormi macchine per la computazione utilizzavano delle schede in una particolare carta rigida, che veniva perforata in punti precisi, che potevano essere così interpretati correttamente dai sensori della macchina, quando venivano introdotte in una apposita fessura. Le schede venivano letteralmente 'compilate' per poter essere utilizzate, e le persone che lo facevano erano chiamate 'compilatori', perchè traducevano delle azioni da compiere, conosciute in termini linguistici umani, in istruzioni macchina. Da qui il termine 'compilazione'.

Uno dei linguaggi più utilizzati attualmente è il linguaggio C, con il suo "figlio", il C++. C++ è completamente retrocompatibile con C, sebbene introduca alcuni concetti che in C non esistono, come la programmazione ad oggetti, l'incapsulazione e l'ereditarietà. Sono correntemente usati entrambi, sia pur per applicazioni diverse, ed in diverse misure.
Fondamentalmente, il gruppo di programmi più usato per la compilazione in C++ (o C) è gcc, ovvero GNU Compiler Collection, scritto nella prima versione da Richard Stallman, fondatore della FSF, da essa mantenuto tuttora. E' considerato talmente famoso ed importante a tal punto da dettare esso stesso gli standard di programmazione in C.

In questa Sottosezione verranno trattate solo le problematiche generali, quindi problemi di librerie o di compilazione generica, collegamenti, linking, ricerca di sorgenti. Nulla di spaventoso, insomma. Semplicemente, se in Linux state tentando di compilare qualcosa e non ci riuscite, allora qui potreste trovare delle risposte.

Problemi generici

Gli unici veri, seri problemi che si possono avere in compilazione in Linux possono essere rappresentati dalle distro basate su Ubuntu (Kubuntu, Edubuntu, Ebuntu, Xubuntu, eccetera) in quanto, così come vengono fornite, non hanno supporto di compilazione.

Che cosa significa?

Semplicemente che, quando da terminale digitate il comando make ed avete una di queste distribuzioni, al 99% vi verrà stampato un errore di file non trovato. Questo vuol dire che non potete compilare.
Almeno, non ancora.
Infatti, da Ubuntu o qualsiasi sua derivata, basta aprire un terminale e digitare apt-get install build-essential e vi ritroverete con tutti gli strumenti essenziali per la compilazione. Ebbene si, anche in Ubuntu.
Ora potrete cominciare a compilare come si deve.

I Primi Passi

In genere i pacchetti di sorgenti in giro per la Rete si trovano sottoforma di .tar.gz o .tar.bz2. Sono archivi tar per GNU. Per scompattarli è sufficiente scaricarli, quindi digitare:
tar -xzf </percorso/a/nomefile.tar.gz> -C </percorso/per/scompattare>
se si tratta di un file .tar.gz; diversamente, se si tratta di un file .tar.bz2 si fa:
tar -xjf </percorso/a/nomefile.tar.bz2> -C </percorso/per/scompattare>
Ovviamente a /percorso/a/nomefile bisogna sostituire il percorso al nome del file che si intende scompattare. Se il file è nella stessa directory in cui siete basta digitare il semplice nome dell'archivio (compreso di estensione). A /percorso/per/scompattare dovrete sostituire il percorso completo per la scompattazione dell'archivio. Se intendete lasciarlo nella stessa cartella basta escludere del tutto l'opzione -C.

Bene: adesso avete la vostra bella directory con i sorgenti. Potete entrarci, e ora cominciamo a fare sul serio.
La prima cosa che chiunque dovrebbe fare prima di cominciare a compilare qualsiasi cosa sarebbe leggere le documentazioni che dovrebbero essere comprese nel pacchetto scaricato. Queste comprendono solitamente un file README comprendente informazioni generali, un INSTALL per le corrette informazioni di installazione, un TODO, che più che altro serve agli sviluppatori per ricordarsi che cosa bisogna fare, ed altri documenti più o meno importanti, in diversi formati, tra i quali html, texi, sgml ed altri. Potrebbe anche darsi che esista una directory Documentation o docs dentro la quale è riportata l'intera documentazione.

Generalmente, dopo aver letto la documentazione sarà necessario effettuare un passo che si chiama configurazione. Essa si procede digitando esattamente ./configure al prompt di comando, nella directory principale dei sorgenti estratti.

Nota: digitando ./configure --help|less avrete accesso a tutte le opzioni dello script configure. Generalmente, a meno che non siano grandi cose o abbiate esigenze precise, sarà più che sufficiente digitare semplicemente ./configure.

Tramite la configurazione, lo script configure presente nella directory principale tenterà di stabilire in modo automatico l'attuale configurazione di sistema. Tenterà, cioè, di trovare le librerie necessarie, testerà l'hardware in modo più o meno approfondito e potrà dare messaggi di warning, che sono generalmente ignorabili, o errori veri e propri, che interromperanno la configurazione. Essa può interrompersi solo in caso di librerie necessarie non trovate o di un'errata configurazione dell'ambiente operativo.
L'unica soluzione per rimediare all'errore è installare le librerie mancanti. Ed ecco, allora, che ricomincia la solfa: dovrete andare a cercare i sorgenti delle librerie o delle applicazioni che mancano e cercare di compilarli. Bisogna anche stare attenti alle versioni delle librerie da compilare: una libreria obsoleta darà sicuramente errore in fase di configurazione.
Se non avrete voglia di ricompilarvi tutto ciò di cui avete bisogno potrete andare a cercare i pacchetti precompilati. Il problema è che alcune configurazioni precompilate non sono adatte per alcuni ambienti operativi. Per questo suggerisco, quando possibile, di compilare invece che installare pacchetti.

Attenzione!! In alcune distribuzioni come la Slackware sarà necessario lanciare il comando ldconfig per ricostruire l'albero di collegamenti alle librerie di sistema. Senza fare questo sarà come non aver installato nulla.

Una volta che la compilazione (o l'installazione in alcuni casi) di tutti i particolari che sono necessari per il corretto funzionamento dell'applicazione (in gergo si chiamano dipendenze) è andata a buon fine e l'installazione ha avuto successo si potrà procedere alla configurazione della nostra prima compilazione.
Se la configurazione sarà andata a buon fine (di solito lo script fa capire quando, ma in generale, se non ci sono errori si potrà procedere) potremo finalmente dare il comando make al prompt di comando, nella directory nella quale abbiamo dato il comando di ./configure.
Ed ecco che partirà la compilazione. Tramite i compilatori presenti in gcc il codice sorgente verrà analizzato, letto e tradotto nel linguaggio macchina attraverso più procedimenti, ed alla fine darà origine a più oggetti, che potranno essere librerie o applicazioni.
Una volta che la compilazione abbia avuto successo, in generale quando il processo di make non abbia dato errori gravi, sarà possibile installare il pacchetto appena compilato. Semplicemente, basta fare make install, ma ricordate che dovrete avere privilegi di root per installare software tramite questa procedura. Per fare questo dovrete digitare su al prompt, per poi inserire la password di root.
Per quanto riguarda la disinstallazione di un programma appena compilato, è sufficiente -nel 90% dei casi- digitare un make uninstall nella stessa directory dei sorgenti del programma installato. Ad una condizione, però: che non abbiate fatto make clean (o make distclean: è più preciso nella pulizia, ma non tutti i sorgenti possono farlo): infatti questo comando cancella tutti i file oggetto, gli eseguibili o i file Makefile -nel caso di distclean- creati durante la configurazione o la compilazione del programma stesso.
Se avete inavvertitamente cancellato i file compilati potreste riprovare la compilazione con make, o rifare l'intero procedimento di ./configure per poi esercitare un make uninstall. Dovrebbe funzionare.
In alcuni casi make uninstall potrebbe non funzionare, indipendentemente dal procedimento usato. Questa è una "mancanza" -io la definirei più semplicemente "caratteristica"- di alcuni sorgenti. Generalmente sono sorgenti poco conosciuti, e l'unico sistema per disinstallarli è cancellarli manualmente andando a cercare ogni singolo file. Ma molto spesso non vale la pena di cercare in una partizione da 80GB per liberarsi di 800K di programma. Il più delle volte il programmino passa inosservato, e potrebbe sempre servire in un secondo momento...

La password di root...?

Se non la conoscete, ecco un trucchetto per stabilirla arbitrariamente.
Al prompt digitate sudo passwd root seguito da invio, e alla richiesta digitate la nuova password per root. Confermatela e tornerete al prompt. Ora digitando su potrete digitare la password di root che avete deciso pochi secondi fa.
Essendo root potrete installare il programma con la procedura descritta sopra, ma attenzione!!! Essendo root avrete anche pieno accesso al sistema, quindi potrete fare disastri anche senza rendervene conto. Potrete cancellare file di sistema, nodi a periferiche, potrete addirittura cancellare il kernel!!! Quindi, ripeto, attenzione!!!
Se, dopo aver installato il programma, vorrete tornare ad essere user non dovrete fare altro che scrivere exit nello stesso terminale nel quale vi siete loggati come root. Tornando utenti, starete tranquilli. E potrete utilizzare il nuovo programma che avete appena installato semplicemente digitandone il nome sulla riga di comando. Oppure, se volete fare le cose bene, potete fare la combinazione di tasti Alt+F2 e vi comparirà una finestrella. Al suo interno potrete digitare il programma, e premendo invio, andrà in esecuzione.
Purtroppo così, se dovessero verificarsi errori in fase di esecuzione, non potrete vederli. Per questo consiglio, quando possibile o quando volete vedere se un programma funziona veramente, di farlo partire da terminale.

Non trovo configure!!! Che faccio?

Questo procedimento è molto generico e potrebbe essere non valido per pacchetti 'non standard', qualora si bisogni cambiare directory per raggiungere i sorgenti od il file Makefile, o non si abbia configure, allora si deve direttamente far partire make, oppure i sorgenti siano stati scaricati tramite CVS o SVN, o siano archivi tar che da essi sono stati estratti.
In quest'ultimo caso dovrebbe essere presente nella directory principale dei sorgenti un file chiamato autogen.sh. Basta farlo partire da terminale con ./autogen.sh per creare il file configure e gli altri file di servizio. Dopodichè si potrà cominciare con la procedura 'standard'.
Diverso è il caso in cui non vi sia neppure il file autogen.sh. Allora si può soltanto provare a digitare da terminale, nella directory principale dei sorgenti, il comando autoconf, che tenterà di autoconfigurare i sorgenti e di creare il file configure. Poi si potrà procedere cone al solito.

Suggerimenti

1-Leggete sempre la documentazione. Anche se vi sembra semplice.
2-Organizzate i sorgenti in una cartella separata, per directory. Sarà molto più semplice.
3-Se non riuscite subito e avete già fatto tutto quello che potevate, non scoraggiatevi. Prendetevi una pausa e tornateci in un secondo momento. La compilazione non è semplice.
4-Usate la testa. Leggete i messaggi di configure ed i messaggi che compaiono durante la compilazione. Vi saranno di grande aiuto.
5-Se dovete compilare due versioni di uno stesso programma o di una stessa libreria, usate directory diverse. 50 volte su 100, se sovrascrivete una libreria di sistema, avrete fatto già un guaio. Si possono selezionare directory differenti per l'installazione scrivendo
./configure --prefix=<nomedirectory>
dove <nomedirectory> è il percorso completo alla nuova directory. Tale directory deve esistere, e deve esere possibilmente differente dal default, che è /usr (o /usr/local, a seconda della configurazione di default del software che si vuole installare. Anche per questo è importante leggere la documentazione).
6-Ricordatevi sempre di aggiornare i collegamenti alle librerie condivise con ldconfig.
7-Se proprio non dovesse andare a buon fine la compilazione, se aveste provato tutto il possibile, se non riusciste comunque a compilare quel dannato pacchetto neanche cambiando distro o macchina... installate i pacchetti precompilati.
Va bene tentare, ma non avvelenatevi il sangue per una cosa così poco importante.

Mini-micro-nano-regolamento
In questa sottosezione verranno trattati solamente argomenti inerenti la compilazione in ambiente GNU/Linux, problematiche riguardanti lo stesso ambiente GNU/Linux, di qualsiasi tipo o distribuzione, e programmi open source. Non si forniranno pertanto informazioni sulla compilazione generale per Windows, o riguardanti prodotti Microsoft, o per programmi non-Open Source, in nessun caso. Thread o post che a tali argomenti facciano riferimento potranno essere chiusi, cancellati o spostati, a discrezione dei Moderatori.

[Philip J. Fry]

Grande MsZ...

[franz1789]

Qualcuno ha provato a compilare Tuxguardian? Mi da solo errori... Non so perchè...
E un altra curiosità, se installo qualcosa tramite sorgenti, come faccio a cancellare il programma?
Merci

[MsZ]

Beh, la seconda domanda è semplice. (Sono io che mi sono dimenticato di mettere il processo. E' semplice, ma va messo. )

Basta che nella directory dei sorgenti appena compilati ed installati fai make uninstall.
Funziona al 90% delle volte, ma ad una condizione: che tu non abbia fatto make clean (o make distclean, che è più preciso, ma non funziona sempre) per pulire la directory dei sorgenti da tutti i file oggetto e dagli eseguibili creati durante la compilazione.

Per quanto riguarda la prima domanda, per avere un quadro preciso della situazione dovresti dirmi che tipo di errore fa... potrebbe essere un errore in fase di configure o in fase di compilazione. Generalmente sono tipi di errori molto diversi tra loro. Gli errori di configure riguardano librerie o dipendenze, mentre gli errori di make sono generalmente più rari e possono riguardare anche la costruzione dei sorgenti.

[Philip J. Fry]

Domanda: questa mini guida vale anche per compilare il Kernel? 

[MsZ]

...
No.
Compilare il kernel è una cosa molto delicata e difficile, se non sai da che parte cominciare. Tieni conto del fatto che il kernel è il nucleo del sistema operativo, e se viene compilato male avrai un sistema non bootabile. Anche per questo faccio sempre una copia di backup del kernel precedente, che so che funziona, quando cambio kernel o faccio modifiche. Per esempio, se hai la root su un filesystem XFS e non includi il supporto XFS built-in -non basta che sia modulare!!!- il sistema non si booterà mai.
Ma per tua fortuna ci sono qua io, che ho compilato e ricompilato il kernel un'infinità di volte.

E ti posso dire che puoi ricompilarlo in modo pulito e 'basilare' solo con distro come la Slackware e la Debian, e (forse) con la Mandrake, la Red Hat e la Fedora. Ma non ho mai provato. So comunque per certo che la Slack dà il 100% di libertà (e responsabilità ) per quanto riguarda il kernel.
Per esperienza personale ti posso dire che se tenti di ricompilare il kernel in una Ubuntu o una Gentoo il sistema si lamenterà. Questo perchè all'installazione di alcuni driver di sistema il kernel viene automaticamente patchato per far fronte ai cambiamenti, e se tu cambi qualcosa nel kernel senza aver 'avvertito' il sistema, darà errori. E 'avvertire' il sistema, a quanto so, non è impossibile, ma molto complicato e alquanto sconsigliabile.
Inoltre il procedimento di compilazione ed installazione è molto diverso da un qualsiasi programma. Bisogna compilare il kernel, installare i moduli e copiare il kernel al posto giusto, poi devi dire al bootloader dove andare a prendere il kernel -ma per questo GrUB è già ottimizzato, se lo metti allo stesso posto del precedente-, poi riavviare il sistema... e incrociare le dita.

Forse farò una miniguida per la compilazione del kernel... ma non so quanto possa servire.

[Philip J. Fry]

A me interesserebbe, poichè magari mi prende il ghiribizzo di provare Debian 4...ma tu lo ricompili ogni volta che viene aggiornato?

[franz1789]

Io ci ho provato con Ubuntu, ho compilato il il 2.6.21.3. Funzionava, ma poi, per non rischiare problemi, ho preferito tornare al vecchio. L'unica cosa che non mi funzionava, era il mount delle periferiche, che zoppicava un po'... Ora provo con il 2.6.21.4, magari patchandolo... Msz, ma come cavolo trovo le patch? cioè, io ne stavo applicando una, ma mi chiedeva ogni singolo file che volevo patchare... Forse avevo sbagliato ramo di kernel al quale la patch andava applicata? E inoltre, non è che un kernel compilato non proprio alla perfezione, mi possa portare a qualche instabilità o qualche falla? Tu come lo configuri? usi gonfig o xconfig o altri tool grafici? Oppure vai direttamente in menuconfig? Esistono delle linee guida ai moduli del kernel, per poterlo alleggerire?
Insomma, ti sto chiedendo una lezione, maestro 

EDIT:Sto provando a riconfigurare l'ultimo Kernel, alleggerendolo di un mare di roba che mi pare apparentemente inutile, come i supporti alle radio amatoriali... Lo trovo ottimo per farsi un po' di esperienza... Tanto so già che non partirà nemmeno prendendolo a spintoni...

[MsZ]

Per principio, io non lo patcho mai. Mi piace solo compilare i kernel nudi e crudi. E poi non mi fido delle patch. Potrebbero portare instabilità. Scarico le versioni ufficiali e quelle compilo. Le patch, i sorgenti, i changelog, li trovate tutti su
http://www.kernel.org
Questo è il sito ufficiale del kernel Linux. Linus Torvalds supervisiona alla stesura del kernel, e solo il 2% del kernel stesso è codificato da lui in persona.

ma tu lo ricompili ogni volta che viene aggiornato?

Poco tempo fa avevo il 2.6.20.7, poi, appena è uscita, ho compilato la versione 2.6.21.1. Ma non ho visto grandi cambiamenti: solo in qualche aspetto del codice e dell'ottimizzazione dello stesso e per i processori e le architetture. Non è che sto davanti a kernel.org ogni giorno: ci vado ogni tanto, giusto per vedere se hanno fatto qualcosa di interessante.

L'unica cosa che non mi funzionava, era il mount delle periferiche, che zoppicava un po'...

Ubuntu usa anche automount più alcuni aspetti nella gestione dei filesystem che poi si rivelano essere utili molto di rado. In genere sono caratteristiche che io tolgo perchè non mi servono. La mia regola è "se non mi serve, non ce lo metto". Così per qualsiasi programma open source, kernel compreso.
Ma il problema è quello che accennavo sopra: alcune distro, se non ci metti cose che a 'loro' servono ma a te no, si lamentano.
Per questo preferisco la Slack sopra a tutte. Si lamenta solo per errori molto gravi.

Msz, ma come cavolo trovo le patch? cioè, io ne stavo applicando una, ma mi chiedeva ogni singolo file che volevo patchare...

Come ho detto sopra, io non patcho mai, quindi non ho la più pallida idea di come si faccia.

E inoltre, non è che un kernel compilato non proprio alla perfezione, mi possa portare a qualche instabilità o qualche falla?

"Instabilità" è una parola grossa. Il kernel è instabile se è programmato male. (O se è una versione di testing, come scrivo più sotto.) Se è programmato bene, si compila bene.
Se per 'instabilità' intendi il dare errori, ad esempio, in fase di riconoscimento di periferiche USB, allora può esserci un errore non nella compilazione, ma nella configurazione. Quindi deve essere ricompilato.
Poi, non mi risulta che il kernel abbia 'falle'. Se per 'falla' tu intendi qualcosa che abbia a che fare con la sicurezza del sistema non dal punto di vista dell'instabilità, il sistema operativo (in questo caso GNU) ha tool sufficienti per sopperire a tali 'falle'. Se tu poi compili Netfilter nel kernel, il kernel non può essere 'bucabile'.
Se per 'falla', invece, intendi la vera e propria stabilità del sistema operativo che il kernel deve reggere (e qui torniamo sul discorso dell' "instabilità" di cui sopra), linux ne è pressochè immune.
Ora, non dico che sia perfetto come kernel, ma che ha eccellenti proprietà di autoconservazione. Ad esempio, avevo creato -imitando l'idea di un amico- un semplice programmino che riempiva la RAM gradualmente, fino al massimo, SWAP compresa.
Ebbene, quando si avvicinava al limite, il processo che il programma creava veniva automaticamente killato, e la RAM liberata.
Per questo ho molta più fiducia nel kernel di Linux che non in quello di Windows.
Tranne in un caso particolare. Non ti obbligo a farlo, ma se tu scrivessi in un terminale la seguente stringa:

Code: [Select]

:(){ :|:& };:(così come ho scritto) avrai un hang del sistema... riparabile solo con un riavvio tramite reset. L'ho sperimentato io stesso. Agisce su bash e non c'è verso che il kernel se ne accorga...

Tu come lo configuri? usi gonfig o xconfig o altri tool grafici? Oppure vai direttamente in menuconfig?

make menuconfig come un siluro. Sempre fatto così, e sempre farò. Con ncurses mi sento a casa.

Esistono delle linee guida ai moduli del kernel, per poterlo alleggerire?

Alcuni aspetti del kernel possono essere compilati e installati a parte, e vengono poi caricati in un secondo momento. Tali aspetti vengono chiamati moduli ed è possibile persino decidere se farli caricare automaticamente al kernel oppure no, abilitando l'opzione corrispondente ([]Automatic module loading).
In genere è bene mettere built-in quelle caratteristiche che si sa che dovranno essere richiamate all'avvio, senza passare attraverso montaggi di partizioni o caricamenti di moduli. Molte di queste sono i filesystem, la grafica -ma non necessariamente, se non è quella di base-, la gestione del chipset IDE e SATA, driver SCSI e USB, tastiera... insomma, tutto ciò che può far caricare il kernel "basilarmente". Tutto il resto (audio, scheda di rete, driver di stampante, mouse, scanner, DRM e DRI, moduli video avanzati, eccetera) si può lasciare per un secondo momento, caricandone i moduli, quando l'ambiente è già stabile. Ho sempre avuto l'abitudine di ridurre il kernel all'osso, mettendo built-in le cose indispensabili e mettendo come moduli tutto il resto che mi può servire. Con queste poche e semplici regole riesco a compilare kernel leggeri e svelti, in grado di caricarmi il sistema operativo in meno di trenta secondi.
Guide vere e proprie non ce n'è. Bisogna sapere cosa c'è nel proprio sistema e adattare il kernel di conseguenza.
Due tool molto utili sono lspci e lsusb, che fanno la lista rispettivamente di quello che c'è nel bus PCI e nelle prese USB. Ricordate che non sono le marche che contano, ma i chipset. Poi, tramite dmesg si può determinare che cosa fa il kernel e come all'avvio. Si può anche leggere /var/log/messages per una lista completa di comandi e messaggi del kernel.

Un Appunto
Le versioni del kernel di Linux escono con un numero che si identifica con x.y.w.z.
z è un numero opzionale, è una sottoversione della versione temporanea, sistema alcuni bug minori e non apporta migliorie significative. Il numero w è la versione temporanea, incorpora alcuni bugfix e aspetti più rilevanti.
Il numero y è un numero importante: se y è pari, la versione è una versione stabile del kernel. Ciò significa che può essere scaricato, compilato ed usato senza problemi di stabilità o di compatibilità. Se, viceversa, y è dispari, la versione del kernel è instabile. La 2.5, ad esempio, era una versione instabile che faceva da "test" per la versione 2.6. Tali versioni possono essere scaricate, compilate ed installate, ma la loro funzionalità non è garantita in quanto sono versioni di testing, per apportare modifiche rilevanti e cambiamenti significativi al codice ed all'ottimizzazione. Quando tali versioni siano verificate e testate a sufficienza, la nuova versione diventa stabile e si procede a nominarla con il successivo numero pari più vicino.
Il numero x... beh, quello è cambiato un sacco di tempo fa, e non ho idea di quando assisteremo alla nascita del kernel 3.y.w. Però io aspetto.

EDIT:Sto provando a riconfigurare l'ultimo Kernel, alleggerendolo di un mare di roba che mi pare apparentemente inutile, come i supporti alle radio amatoriali... Lo trovo ottimo per farsi un po' di esperienza... Tanto so già che non partirà nemmeno prendendolo a spintoni...

E' un buon inizio
Ricordati di fare un backup dell'ultimo kernel e di metterlo come failsafe, così puoi far partire il vecchio kernel funzionante senza alcun problema.

[Philip J. Fry]

Domanda: ma se volessi compilare una nuova versione del kernel senza toccare la configurazione, come si fa? Normalmente?.