www.MegaLab.it

Seconda parte: compilazione

In genere, se la configurazione è andata a buon fine, la compilazione farà altrettanto. Ma se in fase di compilazione trovate degli errori rimediare ad essi può essere più difficile che risolvere i problemi della configurazione. Tuttavia la grande maggioranza degli errori "standard" di compilazione dipendono dalla configurazione, e la loro risoluzione corrisponde alla risoluzione dei relativi errori in configurazione. Un solo tipo di errore si differenzia da essi, ed è l'errore del codice sorgente. [14]

Abbiamo quindi queste comuni tipologie:

• opzioni forzate in configurazione
• errori di dipendenze non verificate
• errori di codice sorgente

Caso: opzioni forzate

Come già detto nella parte sulla configurazione, le opzioni forzate possono influire negativamente sulla compilazione se lo script configure non fa test specifici sulla presenza di determinate librerie o programmi. Nel caso delle opzioni forzate, qui ho tentato di compilare glitz con supporto egl, la cui libreria principale, GLES, non era presente sul mio sistema.

Abilitando egl con

./configure --enable-egl

Lo script da per scontato che le librerie GLES siano installate senza fare alcun test di presenza, e ne conferma l'abilitazione dal sommario:

Tuttavia, provando a compilare glitz con egl l'esito del processo è un evidente fallimento:

Scorrendo le righe del processo troviamo la causa:

dove potete distinguere la causa che da il via alla catena di errori:

error: GLES/egl.h: No such file or directory

Che indica l'assenza nel sistema delle librerie GLES. [15]

Soluzioni possibili

1. Fate riferimento alle soluzioni del caso "opzioni forzate" nella parte di configurazione, sono le stesse.

Caso: errori di dipendenze

Esattamente come le opzioni forzate, gli errori di dipendenza si possono riversare dalla configurazione alla compilazione, e come nella configurazione gli errori di dipendenza possono dipendere da opzioni forzate. Gli effetti di questo problema sono molto più evidenti durante la compilazione.

Una caratteristica evidente che accomuna errori di dipendenze, opzioni forzate e errori di versione in fase di compilazione consiste nel fatto che si risolvono tutte e tre allo stesso modo. Se fate caso all'esempio capirete infatti che nella compilazione lo stesso problema può essere originato da cause diverse. Ho tentato di compilare MPlayer, un software per leggere audio e video, abilitando un codec audio, musepack. Ma, non disponendo di musepack ed essendo lo script di configurazione di MPlayer piuttosto "permissivo" è molto probabile un errore di dipendenza come questo:

(MPC o mpc è un'abbreviazione di musepack, basta fare un breve googling per capirlo. Qui risulta quindi che l'errore riguarda l'assenza di librerie o header musepack.)

Gli esempi di questo tipo sono moltissimi, e come avrete capito errori di dipendenza veri e propri in compilazione non esistono, poiché nel 99% dei casi vengono tutti "smaltiti" e corretti durante le verifiche nella configurazione, se configure è progettato per fare tutti i controlli necessari.

Soluzioni possibili

1. Sono esattamente le stesse che riguardano le opzioni forzate;
2. Se non vi sono opzioni forzate è un errore di dipendenze fondamentali insoddisfatte. Quindi vanno installate le dipendenze necessarie prima di ritentare ial compilazione.

Caso: errori di codice sorgente

Questi errori sono molto più rari, ma possono capitare. Succedono quando il codice sorgente contiene degli errori sintattici o lessicali, e causano l'interruzione della compilazione.

Nell'esempio ho volutamente causato l'interruzione della compilazione di MPlayer con questa invocazione:

./configure --enable-werror

Non è esattamente un errore di codice sorgente, ma simula una situazione di errore del codice. La struttura del messaggio d'errore è più o meno la stessa. L'opzione --enable-werror causa l'interruzione della compilazione in presenza di semplici warning e non di errori veri e propri.

(Potete distinguere la riga cc1: warnings being treated as errors tra i messaggi.)

I warning non sono fatali, ma in alcuni software potrebbero essere indispensabili per controllare che vengano compilati correttamente.

Soluzioni possibili

1. Assicuratevi che l'opzione --disable-werror sia attiva, o che --enable-werror sia disattiva.
2. A volte basta aggiornare i sorgenti, o rimuovere l'albero dei sorgenti per poi ricrearlo dall'archivio, o riscaricarlo.
3. Chiedete consiglio in Internet o direttamente agli sviluppatori.
4. Se avete dimestichezza con il linguaggio in cui il software è scritto potete tentare di correggerlo da soli.
5. Cercate un software che permetta di fare le stesse cose ma che non abbia errori nel codice.