7. Risoluzione dei problemi

Se xmkmf e/o make hanno funzionato senza problemi, potete passare alla prossima sezione. Tuttavia, nella "vita reale", poche cose vanno bene al primo tentativo. È in questi casi che la vostra intraprendenza viene messa alla prova.

7.1 Errori in fase di link

• Supponiamo che make fallisca con un: Link error: -lX11: No such file or directory (Nessun file o directory con quel nome), anche dopo che xmkmf è stato invocato. Ciò potrebbe significare che il file Imake non è stato preparato correttamente. Controllate che nella prima parte del Makefile ci siano delle righe tipo:

  LIB=            -L/usr/X11/lib
  INCLUDE=        -I/usr/X11/include/X11
  LIBS=           -lX11 -lc -lm
  

  Le opzioni -L e -I dicono al compilatore e al linker dove cercare i file library e include, rispettivamente. In questo esempio, le librerie di X11 dovrebbero essere nella directory /usr/X11/lib, e i file include di X11 dovrebbero essere nella directory /usr/X11/include/X11. Se sulla vostra macchina non è così, apportate i cambiamenti necessari al Makefile e riprovate il make.

• Riferimenti non definiti alle funzioni della libreria matematica, come il seguente:

           /tmp/cca011551.o(.text+0x11): undefined reference to `cos'
  

  La soluzione è di linkargli esplicitamente la libreria matematica, aggiungendo un -lm al flag LIB o LIBS nel Makefile (vedere esempio precedente).

• Ancora un'altra cosa da provare se xmkmf fallisce è lo script seguente:

           make -DUseInstalled -I/usr/X386/lib/X11/config
  

  Che è una specie di xmkmf ridotto all'osso.

• In rarissimi casi, l'esecuzione di ldconfig come root potrebbe essere la soluzione:
  # ldconfig aggiorna i link simbolici alla libreria condivisa. Questo potrebbe non essere necessario.

• Alcuni Makefile usano degli alias non riconosciuti per le librerie presenti nel vostro sistema. Per esempio, il binario potrebbe richiedere libX11.so.6, ma in /usr/X11R6/lib non c'è nessun file o link con quel nome. Però, c'è un libX11.so.6.1. La soluzione è di fare un ln -s /usr/X11R6/lib/libX11.so.6.1 /usr/X11R6/lib/libX11.so.6, come root. Ciò potrebbe dover essere seguito da un ldconfig.

• A volte il sorgente necessita delle vecchie librerie nella versione X11R5 per essere compilato. Se avete le librerie R5 in /usr/X11R6/lib (avete avuto la possibilità di installarle durante la prima installazione di Linux), allora dovete solo assicurarvi di avere i link di cui il software ha bisogno per la compilazione. Le librerie R5 sono chiamate libX11.so.3.1.0, libXaw.so.3.1.0, e libXt.so.3.1.0. Di solito vi servono dei link, come libX11.so.3 -> libX11.so.3.1.0. Forse il software avrà bisogno anche di un link del tipo libX11.so -> libX11.so.3.1.0. Naturalmente, per creare un link "mancante", usate il comando ln -s libX11.so.3.1.0 libX11.so, come root.

• Alcuni pacchetti esigeranno l'installazione di versioni aggiornate di una o più librerie. Per esempio, le versioni 4.x della suite StarOffice della StarDivision GmbH erano famose per richiedere libc in versione 5.4.4 o successiva. Anche il più recente StarOffice 5.0 non girerà nemmeno dopo l'installazione con le nuove librerie glibc 2.1. Fortunatamente, il più nuovo StarOffice 5.1 risolve tali problemi. Se avete una versione di StarOffice più vecchia, potreste dover copiare, da root, una o più librerie nelle directory appropriate, rimuovere le vecchie librerie, poi ripristinare i link simbolici (controllate l'ultima versione dello StarOffice miniHOWTO (tradotto) per maggiori informazioni su questo argomento). Attenzione: Usate molta cautela nel fare ciò, poiché potreste rendere non funzionante il vostro sistema se combinate dei pasticci. Potete trovare le librerie più aggiornate presso Sunsite.

7.2 Altri problemi

• Uno script Perl o shell installato vi dà un No such file or directory come messaggio d'errore. In questo caso, controllate i permessi del file per assicurarvi che il file sia eseguibile e controllate l'intestazione del file per accertarvi che la shell o il programma invocato dallo script sia nel posto specificato. Per esempio, lo script potrebbe iniziare con:

  #!/usr/local/bin/perl
  

  Se infatti Perl è installato nella vostra directory /usr/bin invece che nella /usr/local/bin, allora lo script non funzionerà. Ci sono due modi per correggere questo problema. L'intestazione del file script può essere cambiata in #!/usr/bin/perl, o si può aggiungere un link simbolico alla giusta directory, ln -s /usr/bin/perl /usr/local/bin/perl.

• Alcuni programmi X11 richiedono le librerie Motif per la compilazione. Le distribuzioni Linux standard non hanno le librerie Motif installate, e al momento Motif costa 100-200$ extra (sebbene in parecchi casi funzioni anche la versione freeware Lesstif). Se vi serve Motif per la compilazione di un certo pacchetto, ma vi mancano le librerie Motif, può essere possibile ottenere dei binari linkati staticamente. Il linkaggio statico incorpora le routine di libreria nei binari stessi. Ciò si traduce in file binari più grandi, ma il codice girerà sui sistemi in cui mancano le librerie.
  Quando un pacchetto richiede, per la compilazione, delle librerie non presenti sul vostro sistema, ciò provocherà errori in fase di link (errori tipo undefined reference - riferimento non definito). Le librerie potrebbero essere del tipo costoso (proprietà di qualcuno) o difficili da trovare per qualche altra ragione. In tal caso, ottenere un binario linkato staticamente dall'autore del pacchetto, o da un gruppo utenti Linux, può essere il modo più facile per effettuare delle riparazioni.

• Eseguendo uno script configure è stato creato uno strano Makefile, uno che sembra non avere nulla a che fare col pacchetto che state tentando di compilare. Ciò significa che è stato eseguito il configure sbagliato, uno trovato da qualche altra parte nel path. Lanciate sempre configure come ./configure per evitare questo problema.

• La maggior parte delle distribuzioni sono passate alle librerie libc 6 / glibc 2 dalla più vecchia libc 5. I binari precompilati che funzionavano con la vecchia libreria potrebbero andare in bomba se avete aggiornato la libreria. La soluzione è o di ricompilare le applicazioni dal sorgente o di ottenere dei nuovi binari precompilati. Se state aggiornando il vostro sistema a libc 6 e riscontrate dei problemi, fate riferimento al Glibc 2 HOWTO (tradotto) di Eric Green.
  Notate che ci sono delle piccole incompatibilità fra le versioni minori di glibc, così un binario compilato con glibc 2.1 potrebbe non funzionare con glibc 2.0 e vice versa.

• A volte è necessario togliere l'opzione -ansi dai flag di compilazione nel Makefile. Ciò abilita le caratteristiche supplementari di gcc, quelle non-ANSI in particolare, e permette la compilazione di pacchetti che richiedono tali estensioni. (Grazie a Sebastien Blondeel per questa indicazione).

• Alcuni programmi esigono di essere setuid root, per poter essere eseguiti con privilegi di root. Il comando per effettuare ciò è chmod u+s nomefile, come root (osservate che il programma deve già essere di proprietà di root). Questo ha l'effetto di impostare il bit setuid nei permessi del file. Questo problema viene fuori quando il programma accede all'hardware di sistema, come un modem o un lettore CD ROM, o quando le librerie SVGA vengono chiamate dal modo console, come in un particolare noto pacchetto di emulazione. Se un programma funziona quando eseguito da root, ma dà messaggi di errore tipo access denied (accesso negato) ad un utente normale, sospettate che la causa sia questa.

  Avvertimento: Un programma con setuid impostato come root può porre un rischio di sicurezza per il sistema. Il programma gira con privilegi di root ed ha così il potenziale di causare danni significativi. Accertatevi di sapere cosa fa il programma, guardando il sorgente se possibile, prima di impostare il bit setuid.

7.3 Ritocchi e messa a punto

Potreste voler esaminare il Makefile per accertarvi che vengano usate le migliori opzioni di compilazione possibili per il vostro sistema. Per esempio, impostando il flag -O2 si sceglie il più alto livello di ottimizzazione ed il flag -fomit-frame-pointer provoca la generazione di un binario più piccolo (sebbene il debugging sarà così disabilitato). Però non giocherellate con tali opzioni, a meno che non sappiate cosa state facendo, e comunque non prima di aver ottenuto un binario funzionante.

7.4 Dove trovare maggiore aiuto

Nella mia esperienza, forse il 25% delle applicazioni supera la fase di compilazione così com'è, senza problemi. Un altro 50%, o giù di lì, può essere "persuaso" a farlo con uno sforzo variabile da lieve ad erculeo. Questo significa che ancora un numero significativo di pacchetti non ce la faranno, non importa cosa si faccia. In tal caso, i binari Intel ELF e/o a.out di questi potrebbero essere trovati presso Sunsite o presso TSX-11 archive. Red Hat e Debian hanno vasti archivi di binari preimpacchettati della maggior parte dei più popolari software per Linux. Forse l'autore del software può fornire i binari compilati per il vostro particolare tipo di macchina.

Notate che se ottenete i binari precompilati, dovrete controllarne la compatibilità con il vostro sistema:

• I binari devono girare sul vostro hardware (i.e., Intel x86).
• I binari devono essere compatibili con il vostro kernel (i.e., a.out o ELF).
• Le vostre librerie devono essere aggiornate.
• Il vostro sistema deve avere le appropriate utilità di installazione (rpm o deb).

Se tutto il resto non funziona, potete trovare aiuto nei newsgroup appropriati, come comp.os.linux.x o comp.os.linux.development.

Se non funziona proprio niente, almeno avrete fatto del vostro meglio, ed avrete imparato molto.