<!doctype linuxdoc system>

<article OPTS="italian">

<!-- Title information -->

<title>Building and Installing Software Packages for Linux

<author>
<em><url url="mailto:thegrendel@theriver.com"
name="Mendel Cooper"></em>
---
<htmlurl url="http://personal.riverusers.com/~thegrendel/"
name="http://personal.riverusers.com/~thegrendel/">

<date>v1.91, 27 luglio 1999

<abstract>
- Compilazione ed installazione di pacchetti software per Linux -

Questa &egrave; un'ampia guida per compilare ed installare "generiche"
distribuzioni di software UNIX sotto Linux. Vengono inoltre discussi i
formati binari preimpacchettati "rpm" e "deb".

Traduzione di <htmlurl url="mailto:fabrizio_stefani@yahoo.it"
name="Fabrizio Stefani">, 23 settembre 1999.
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

<sect>Introduzione
<p>
Parecchi pacchetti software per i vari dialetti di UNIX e Linux sono dati
come archivi compressi di file sorgenti. Lo stesso pacchetto pu&ograve; essere
"compilato" per girare su differenti macchine fissate, e ci&ograve; risparmia
l'autore del software dal dover produrre versioni multiple. Una singola
versione di un pacchetto software pu&ograve; cos&igrave; finire col girare, in
varie incarnazioni, su una macchina Intel, un DEC Alpha, una workstation RISC,
o anche un mainframe. Sfortunatamente, questo scarica la
responsabilit&agrave; della effettiva "compilazione" ed installazione del
software sull'utente finale, l'&laquo;amministratore di sistema&raquo; de 
facto, il tizio seduto alla tastiera -- voi. Fatevi coraggio, comunque, il 
processo non &egrave; poi cos&igrave; terrificante o misterioso come sembra, 
come dimostrer&agrave; questa guida.



<sect>Spacchettare i file
<p>
Avete scaricato o vi siete procurati in altro modo un pacchetto software.
Molto probabilmente &egrave; archiviato (in formato <em>tar</em>) e compresso
(in formato <em>gzip</em>), e quindi il nome del file terminer&agrave; con
<tt>.tar.gz</tt> o <tt>.tgz</tt> (N.d.T: Gli archivi tar compressi, in inglese,
vengono colloquialmente detti "tarball", d'ora in poi ci riferiremo ad 
essi come "pacchetti tar"). Innanzi tutto copiatelo in una directory di 
lavoro. Poi decomprimetelo (con <em>gunzip</em>) e spacchettatelo (con 
<em>tar</em>). Il comando appropriato per farlo &egrave; <bf>tar xzvf
<em>nomefile</em></bf>, dove <em>nomefile</em> &egrave; il nome del file,
ovviamente. Il processo di dearchiviazione generalmente installer&agrave; i
file appropriati nelle sottodirectory che avr&agrave creato. Notate che se
il nome del pacchetto ha suffisso <em>.Z</em>, la procedura su esposta
sar&agrave; ancora buona, sebbene funzioni anche eseguire <bf>uncompress</bf>,
seguito da <bf>tar xvf</bf>. Potete vedere un'anteprima di tale processo
con <bf>tar tzvf nomefile</bf>, che elenca i file contenuti nell'archivio
senza in effetti estrarli.

Il suddetto metodo per spacchettare i pacchetti tar &egrave; equivalente ad
uno o l'altro dei seguenti:
<itemize>
<item>gzip -cd nomefile | tar xvf -
<item>gunzip -c nomefile | tar xvf -
</itemize>
(Il '-' forza il comando <em>tar</em> a prendere il suo input dallo
<tt>stdin</tt>.)

I file sorgenti nel nuovo formato <em>bzip2</em> (<tt>.bz2</tt>)
possono essere estratti con un <bf>bzip2 -cd nomefile | tar xvf -</bf>,
o, pi&ugrave; semplicemente, con un <bf>tar xyvf nomefile</bf>, sempre
che <tt>tar</tt> sia stato opportunamente corretto con l'apposita 
patch (riferirsi al
<htmlurl url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/mini/Bzip"
name="Bzip2.HOWTO"> <ref id="traduzioni" name="(tradotto)"> per i dettagli).
La distribuzione Linux di Debian usa una diversa patch per <tt>tar</tt>, 
scritta da Hiroshi Takekawa, che, in quella particolare versione 
di <tt>tar</tt>, usa le opzioni <em>-I, --bzip2, --bunzip2</em>.
 
[Grazie tante a R. Brock Lynn e Fabrizio Stefani per le correzioni e gli
aggiornamenti sull'informazione sopra citata]


A volte i file archiviati devono essere estratti, usando tar, ed installati
dalla home directory dell'utente, o magari in una cert'altra directory, tipo
<tt>/</tt>, <tt>/usr/src</tt>, o <tt>/opt</tt>, come specificato nelle 
informazioni di configurazione del pacchetto. Qualora si riceva un messaggio 
di errore tentando l'estrazione dall'archivio, questa potrebbe esserne la
ragione. Leggete i file di documentazione del pacchetto, specialmente i file
<tt>README</tt> e/o <tt>Install</tt>, se presenti, ed editate i file di 
configurazione e/o i <tt>Makefile</tt> come necessario, consistentemente con 
le istruzioni di installazione. Osservate che di solito <bf>non</bf> si 
dovrebbe modificare il file <tt>Imake</tt>, poich&eacute; ci&ograve; potrebbe 
avere conseguenze impreviste. La maggior parte dei pacchetti permettono di 
automatizzare questo processo eseguendo <bf>make install</bf> per mettere i 
binari nelle appropriate aree di sistema.

<itemize>
<item>Potreste incontrare file <tt>shar</tt>, o <em>archivi shell</em>,
specialmente sui newsgroup riguardanti il codice sorgente in Internet. 
Questi vengono ancora usati perch&eacute; sono in formato testo, e
ci&ograve; permette ai moderatori dei newsgroup di consultarli e respingere
quelli inadatti. Essi possono essere spacchettati col comando
<bf>unshar nomefile.shar</bf>.
Altrimenti la procedura per trattarli &egrave; la stessa dei pacchetti tar.

</itemize>


<itemize>

<item>Alcuni archivi sorgente sono stati manipolati usando utilit&agrave; di
compressione non standard DOS, Mac o anche Amiga, tipo <em>zip</em>,
<em>arc</em>, <em>lha</em>, <em>arj</em>, <em>zoo</em>, <em>rar</em>,e 
<em>shk</em>. Fortunatamente, <url url="http://metalab.unc.edu" 
name="Sunsite"> e altri posti hanno delle utilit&agrave; di decompressione
per Linux che possono trattare molti o tutti tali formati.

</itemize>

Occasionalmente, potrebbe essere necessario aggiungere delle correzioni 
per dei bug o aggiornare i file sorgenti estratti da un archivio usando
un file <tt>patch</tt> o <tt>diff</tt> che elenca le modifiche. I file
di documentazione e/o <tt>README</tt> vi informeranno se
ci&ograve; &egrave; necessario. La normale sintassi per invocare la potente
utilit&agrave; di <em>patch</em> di Larry Wall &egrave; <bf>patch <
patchfile</bf>.

Ora potete procedere alla fase di compilazione del processo.




<sect>Usare make
<p>
Il <tt>Makefile</tt> &egrave; la chiave del processo di compilazione. Nella
sua forma pi&ugrave; semplice, un Makefile &egrave; uno script per la
compilazione, o building, dei "binari", le parti eseguibili di un pacchetto.
Il Makefile pu&ograve; anche fornire un mezzo per aggiornare un pacchetto
software senza dover ricompilare ogni singolo file sorgente in esso, ma 
questa &egrave; un'altra storia (o un altro articolo).

Ad un certo punto, il Makefile lancia <tt>cc</tt> o <tt>gcc</tt>. Questo
in realt&agrave; &egrave; un preprocessore, un compilatore C (o C++), ed un
linker, invocati in quell'ordine. Questo processo converte il sorgente nei
binari, i veri eseguibili.

L'invocazione di <em>make</em> di solito richiede solo di battere 
<bf>make</bf>. Ci&ograve;, generalmente, serve a compilare tutti i file
eseguibili necessari per il pacchetto in questione. Tuttavia, make
pu&ograve; svolgere anche altri compiti, come installare i file nelle loro
directory appropriate (<bf>make install</bf>) e rimuovere i file oggetto 
stantii (<bf>make clean</bf>). L'esecuzione di <bf>make -n</bf> permette di
vedere un'anteprima del processo di compilazione, poich&eacute; stampa tutti
i comandi che sarebbero attivati da un make, ma senza in effetti eseguirli.


Solo i software pi&ugrave; semplici usano un Makefile generico. Le 
installazioni pi&ugrave; complesse richiedono un Makefile su misura secondo 
la posizione delle librerie, dei file include e delle risorse sulla vostra
specifica macchina. Questo, in particolare, &egrave; il caso che si ha quando 
durante il processo di compilazione servono le librerie <tt>X11</tt> per 
l'installazione. <em>Imake</em> e <em>xmkmf</em> adempiono questo compito.

Un <tt>Imakefile</tt> &egrave;, per citare la pagina di manuale, un 
"prototipo" di Makefile. L'utilit&agrave; imake costruisce un Makefile adatto 
al vostro sistema dall'Imakefile. Nella maggior parte dei casi, tuttavia, 
preferirete eseguire <bf>xmkmf</bf>, uno script shell che invoca imake,
un suo front end. Controllate il file README o INSTALL incluso 
nell'archivio per istruzioni specifiche (se, dopo aver estratto
dall'archivio i file sorgenti, &egrave; presente un file <tt>Imake</tt> nella
directory base, &egrave; un chiaro segno che dovrebbe essere eseguito
<bf>xmkmf</bf>). Leggere le pagine di manuale di <tt>Imake</tt> e 
<tt>xmkmf</tt> per una pi&ugrave; dettagliata analisi della procedura.

&Egrave; bene essere consapevoli che <tt>xmkmf</tt> e <tt>make</tt> potrebbero
dover essere invocati come root, specialmente nel fare un <bf>make install</bf>
per spostare i binari sulle directory <tt>/usr/bin</tt> o 
<tt>/usr/local/bin</tt>. Usare make come utente normale, senza privilegi di
root, porter&agrave; probabilmente a dei messaggi d'errore tipo <em>write access
denied</em> (accesso in scrittura negato), perch&eacute; manca il permesso per
la scrittura nelle directory di sistema. Controllate anche che i binari creati 
abbiano i giusti permessi di esecuzione per voi ed ogni altro utente 
appropriato.

Quando viene invocato, <bf>xmkmf</bf> usa il file <tt>Imake</tt> per 
costruire il Makefile appropriato per il vostro sistema. Sarete 
soliti invocare <bf>xmkmf</bf> con l'argomento <bf>-a</bf>, per effettuare 
automaticamente <em>make Makefiles</em>, <em>make includes</em> e 
<em>make depend</em>. Ci&ograve; imposta le variabili e definisce le posizioni
delle librerie per il compilatore ed il linker. A volte, non ci
sar&agrave; il file <tt>Imake</tt>, ci sar&agrave; invece uno script
<tt>INSTALL</tt> o <tt>configure</tt>, che dovrebbe essere invocato come
<bf>./configure</bf> per assicurarsi che venga chiamato il giusto script
<tt>configure</tt>. Nella maggior parte dei casi, il file <tt>README</tt>
incluso con la distribuzione spiegher&agrave; la procedura di installazione.

&Egrave; di solito una buona idea guardare dentro il <tt>Makefile</tt> che
<tt>xmkmf</tt>, o uno degli script di installazione, costruiscono. Il
Makefile sar&agrave; di solito adatto per il vostro sistema, ma 
occasionalmente potrebbe essere necessario "ritoccarlo" o correggere 
manualmente degli errori.


Per installare i binari appena compilati nelle appropriate directory di
sistema di solito basta eseguire, come root, <bf>make install</bf>.
Solitamente, le directory per i binari del sistema sulle moderne 
distribuzioni Linux sono <tt>/usr/bin</tt>, <tt>/usr/X11R6/bin</tt>, e
<tt>/usr/local/bin</tt>. La directory da preferire per i nuovi pacchetti
&egrave; <tt>/usr/local/bin</tt>, poich&eacute; in tal modo si terranno
separati i binari che non fanno parte della installazione Linux originale.

I pacchetti originariamente mirati per versioni commerciali di UNIX
potrebbero provare ad installarsi in <tt>/opt</tt> o in un'altra directory
sconosciuta. Ci&ograve;, naturalmente, causer&agrave; un errore di
installazione se la directory in questione non esiste. Il modo
pi&ugrave; semplice per risolvere questo problema &egrave; quello di creare,
come root, una directory <tt>/opt</tt>, lasciare che il pacchetto vi si
installi, e poi aggiungere tale directory alla variabile d'ambiente
<tt>PATH</tt>. Oppure, potete creare dei link simbolici alla directory
<tt>/usr/local/bin</tt>.

La procedura di installazione generale sar&agrave; quindi:
<itemize>
<item>Leggere il file <tt>README</tt> ed altri file di documentazione 
appropriati.
<item>Eseguire <bf>xmkmf -a</bf>, o lo script <tt>INSTALL</tt> o 
<tt>configure</tt>.
<item>Controllare il <tt>Makefile</tt>.
<item>Se necessario, eseguire <bf>make clean</bf>, <bf>make Makefiles</bf>,	
<bf>make includes</bf>, e <bf>make depend</bf>.
<item>Eseguire <bf>make</bf>.
<item>Controllare i permessi.
<item>Se necessario, eseguire <bf>make install</bf>.
</itemize>


<em>Note:</em>

<itemize>
<item>Normalmente non si compilano i pacchetti come root. L'effettuare un
<bf>su</bf> a root &egrave; necessario solo per installare i binari compilati
nelle directory di sistema.

<item>Una volta che avete preso confidenza con <em>make</em> e col suo uso,
potreste volere che vengano aggiunte nel <tt>Makefile</tt> standard
incluso nel  (o creato col) pacchetto che state installando delle
opzioni di ottimizzazione aggiuntive. Alcune di tali opzioni, le pi&ugrave; usate, sono <em>-O2</em>,
<em>-fomit-frame-pointer</em>, <em>-funroll-loops</em> e <em>-mpentium</em>
(se usate un processore Pentium). Siate cauti e fatevi guidare dal buon senso
quando modificate un <tt>Makefile</tt>!

<item>Dopo che <em>make</em> ha creato i binari, potreste voler usare 
<bf>strip</bf> su essi. Il comando <bf>strip</bf> elimina dai file binari le
informazioni per il debugging simbolico e ne riduce la dimensione, spesso 
drasticamente. Ovviamente ci&ograve; disabiliter&agrave; il debugging.

<item>Il <url url="http://sunsite.auc.dk/pack/" name="Pack Distribution
Project"> utilizza un diverso approccio per la creazione di archivi di 
pacchetti software, basato su un insieme di strumenti scritti in Python per
la gestione di link simbolici a file installati in <em>directory di 
raccolta</em> separate. Questi archivi sono degli ordinari <em>pacchetti 
tar</em>, ma si installano nelle directory <tt>/coll</tt> e <tt>/pack</tt>. 
Potreste dover scaricare il <em>Pack-Collection</em> dal suddetto sito
qualora vi capiti di imbattervi in una di tali distribuzioni.
</itemize>



<sect>Binari preimpacchettati
<p>

<sect1> Cosa c'&egrave; che non va negli rpm?
<p>

La compilazione e l'installazione manuale dei pacchetti dal sorgente
&egrave; un compito apparentemente cos&igrave spaventoso per alcuni utenti
Linux che essi hanno abbracciato i popolari formati di pacchetti <em>rpm</em>
e <em>deb</em>, o il pi&ugrave; recente Stampede <em>slp</em>. Sebbene possa essere
vero che l'installazione di un <em>rpm</em> di solito procede tanto facilmente
e tanto velocemente quanto l'installazione del software di un certo altro noto
sistema operativo, &egrave; il caso di spendere qualche parola riguardo gli
svantaggi della installazione-fai-da-te dei binari preimpacchettati.

Primo, sappiate che i pacchetti software vengono di solito rilasciati
inizialmente come pacchetti tar, e i binari preimpacchettati li seguono 
giorni, settimane, persino mesi dopo. Un pacchetto <em>rpm</em> corrente
&egrave; tipicamente almeno un paio di versioni minori indietro rispetto
all'ultimo pacchetto tar. Quindi, se desiderate stare al passo con tutto il 
software dell'ultima generazione, potreste non voler aspettare che appaia 
un <em>rpm</em> o un <em>deb</em>. Alcuni pacchetti meno popolari potrebbero 
non essere mai convertiti in <em>rpm</em>.

Secondo, il pacchetto tar potrebbe facilmente essere pi&ugrave; completo,
avere pi&ugrave; opzioni, e prestarsi meglio ad una personalizzazione ed una
messa a punto. La versione binaria rpm potrebbe non avere alcune delle
funzionalit&agrave; della versione completa. Gli <em>rpm</em> sorgenti
contengono il codice sorgente completo e sono equivalenti ai corrispondenti
pacchetti tar, e allo stesso modo necessitano di essere compilati ed
installati usando l'opzione <bf>rpm --recompile nomepacchetto.rpm</bf>
oppure <bf>rpm --rebuild nomepacchetto.rpm</bf>.

Terzo, alcuni binari preimpacchettati non si installano bene, e anche se
si installano, potrebbero piantarsi e fare un core dump. Essi potrebbero
dipendere da versioni di libreria diverse da quelle presenti nel vostro
sistema, o potrebbero essere stati preparati impropriamente o essere
semplicemente difettosi. Ad ogni modo, quando installate un <em>rpm</em> o 
un <em>deb</em> necessariamente fate affidamento sulla competenza delle 
persone che hanno preparato quel pacchetto.

Infine, aiuta avere il codice sorgente in mano, per poter effettuare delle
riparazioni ed imparare da esso. &Egrave; molto pi&ugrave; conveniente avere il
sorgente nell'archivio da cui si stanno compilando i binari, piuttosto che
in un differente pacchetto <em>rpm</em>.


L'installazione di un pacchetto <em>rpm</em> non &egrave; necessariamente una
bazzecola. Se c'&egrave; un conflitto di dipendenza, l'installazione
dell'<em>rpm</em> fallir&agrave;. L'<em>rpm</em> potrebbe richiedere una
versione delle librerie diversa da quelle presenti sul vostro sistema,
l'installazione potrebbe non funzionare, anche se create dei link
simbolici alle librerie mancanti da quelle a posto. Malgrado la loro
convenienza, le installazioni degli <em>rpm</em> spesso falliscono per le
stesse ragioni per cui lo fanno quelle dei pacchetti tar.

Dovete installare gli <em>rpm</em> e i <em>deb</em> come root, per avere i
necessari permessi di scrittura, e ci&ograve; apre un buco di sicurezza
potenzialmente serio, poich&eacute; potreste inavvertitamente massacrare i
binari di sistema e le librerie, o anche installare un <em>cavallo di
Troia</em> che potrebbe liberare il caos sul vostro sistema. &Egrave; quindi
importante ottenere pacchetti <em>rpm</em> e <em>deb</em> da una "fonte
fidata". In ogni caso, dovreste eseguire una 'verifica della firma' 
(rispetto ad un codice di controllo MD5) sul pacchetto, <bf>rpm 
--checksig nomepacchetto.rpm</bf>, prima di installarlo. Allo stesso 
modo &egrave; fortemente raccomandata l'esecuzione di <bf>rpm -K --nopgp 
nomepacchetto.rpm</bf>. I comandi corrispondenti per i pacchetti
<em>deb</em> sono <bf>dpkg -I | --info nomepacchetto.deb</bf> e
<bf>dpkg -e | --control nomepacchetto.deb</bf>.

<itemize>
<item><tt>rpm --checksig gnucash-1.1.23-4.i386.rpm</tt>
<tscreen><verb>
</verb></tscreen>
<tt>gnucash-1.1.23-4.i386.rpm: size md5 OK</tt>
</itemize>

<itemize>
<item><tt>rpm -K --nopgp gnucash-1.1.23-4.i386.rpm</tt>
<tscreen><verb>
</verb></tscreen>
<tt>gnucash-1.1.23-4.i386.rpm: size md5 OK</tt>
</itemize>

Per i tipi veramente paranoici (e in questo caso ci sarebbe
molto da dire a proposito di paranoia), ci sono le utilit&agrave; 
<em>unrpm</em> e <em>rpmunpack</em> disponibili presso la <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/utils/package" name="directory
utils/package di Sunsite"> per estrarre e controllare i singoli
componenti dei pacchetti.

<url url="mailto:klee@debian.org" name="Klee Diene"> ha scritto il pacchetto
sperimentale <em>dpkgcert</em>, per la verifica dell'integrit&agrave; dei file
<em>.deb</em> installati, usando i codici di controllo MD5.
&Egrave; disponibile nell'<url 
url="ftp://ftp.debian.org/pub/debian/project/experimental"
name="archivio ftp Debian">. L'attuale nome / versione &egrave;
<em>dpkgcert_0.2-4.1_all.deb</em>. Il sito <url
url="http://dpkgcert.jimpick.com" name="Jim Pick Software"> mantiene un
server database sperimentale per fornire certificati <em>dpkgcert</em>
per i pacchetti di una tipica installazione Debian.

Nella loro forma pi&ugrave; semplice, i comandi <bf>rpm -i
nomepacchetto.rpm</bf> e <bf>dpkg --install nomepacchetto.deb</bf>
automaticamente aprono il pacchetto ed installano il software. Siate cauti,
comunque, poich&eacute; usare tali comandi ciecamente pu&ograve; essere
pericoloso per la salute del vostro sistema!

Notate che gli avvertimenti suddetti si applicano anche, sebbene in
minor misura, all'utilit&agrave; di installazione <em>pkgtool</em> della
Slackware. Tutto il software di installazione "automatico" richiede
cautela.

I programmi <url
url="http://www.people.cornell.edu/pages/rc42/program/martian.html"
name="martian"> e <url url="http://kitenet.net/programs/alien/"
name ="alien"> permettono la conversione tra i formati dei pacchetti
<em>rpm</em>, <em>deb</em>, Stampede <em>slp</em> e <em>tar.gz</em>.
Ci&ograve; rende questi pacchetti accessibili a tutte le distribuzioni Linux.

Leggere attentamente le pagine di manuale dei comandi <em>rpm</em>
e <em>dpkg</em>, e fare riferimento all'<htmlurl
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/RPM-HOWTO" name="RPM
HOWTO">, alla 
<url url="http://www.tfug.org/helpdesk/linux/rpm.html"
name="Quick Guide to Red Hat's Package Manager"> del TFUG, e a <url
url="http://www.debian.org/doc/FAQ/debian-faq-7.html" name="The Debian
Package Management Tools"> per informazioni pi&ugrave; dettagliate.

<sect1>Problemi con gli rpm: un esempio
<p>
 
<url url="mailto:hubicka@paru.cas.cz" name="Jan Hubicka"> ha scritto un
bellissimo pacchetto per i frattali, chiamato <em>xaos</em>. Sulla sua
<url url="http://www.paru.cas.cz/~hubicka/XaoS" name="home page"> sono
disponibili entrambi i pacchetti <tt>.tar.gz</tt> e <tt>rpm</tt>. In nome 
della comodit&agrave; proviamo la versione rpm, piuttosto che il pacchetto
tar.

Sfortunatamente, l'rpm di <em>xaos</em> non si installa. Due diverse 
versioni rpm fanno i capricci.
 
<bf>rpm -i --test XaoS-3.0-1.i386.rpm</bf>
<tscreen><verb>
error: failed dependencies:
        libslang.so.0 is needed by XaoS-3.0-1
        libpng.so.0 is needed by XaoS-3.0-1
        libaa.so.1 is needed by XaoS-3.0-1
</verb></tscreen>

<bf>rpm -i --test xaos-3.0-8.i386.rpm</bf>
<tscreen><verb>
error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8
</verb></tscreen>

La cosa strana &egrave; che <tt>libslang.so.0</tt>, <tt>libpng.so.0</tt>,
e <tt>libaa.so.1</tt> sono tutte presenti nella directory <tt>/usr/lib</tt>
del sistema usato. Gli rpm di <em>xaos</em> devono essere stati compilati
con delle versioni leggermente diverse di quelle librerie, anche se i
numeri di versione sono identici.

Come test, proviamo ad installare <tt>xaos-3.0-8.i386.rpm</tt> con l'opzione
<em>--nodeps</em> per forzarne l'installazione. Provando ad eseguire 
<em>xaos</em> si pianta.

<tscreen><verb>
xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl
</verb></tscreen>

(errore nel caricamento delle librerie condivise, il simbolo __fabsl non
&egrave; definito) 

Cerchiamo testardamente di andare in fondo alla cosa. Lanciando <em>ldd</em>
sul binario di <em>xaos</em>, per trovare da quali librerie dipende, vediamo
che le librerie necessarie ci sono tutte. Lanciando <em>nm</em> sulla 
libreria <tt>/usr/lib/libaa.so.1</tt>, per vedere i suoi riferimenti
simbolici, ci accorgiamo che <em>__fabsl</em> manca davvero. Naturalmente
il riferimento che manca <em>potrebbe</em> non essere presente in una
qualsiasi delle altre librerie... Non c'&egrave; niente da fare, salvo
rimpiazzare una o pi&ugrave; librerie.

Basta! Scarichiamo il pacchetto tar, <tt>XaoS-3.0.tar.gz</tt>,
disponibile sul <url url="ftp://ftp.ta.jcu.cz/pub/linux/hubicka/XaoS/3.0" 
name="sito ftp"> o reperibile dalla home page. Proviamo a compilarlo.
L'esecuzione di <bf>./configure</bf>, <bf>make</bf> e infine (come root) 
<bf>make install</bf> procede senza intoppi.

Questo &egrave; solo uno fra i tanti esempi di binari preimpacchettati
che portano pi&ugrave; problemi che vantaggi.




<sect>Problemi riguardo termcap e terminfo
<p>


Secondo la pagina di manuale, <em>"terminfo &egrave; un database che 
descrive i terminali, usato da programmi orientati-allo-schermo..."</em>.
Esso definisce un generico insieme di sequenze di controllo
(codici di escape) usati per mostrare il testo sui terminali, e
rende possibile il supporto per differenti terminali hardware
senza la necessit&agrave; di driver speciali. Le librerie <em>terminfo</em> 
si trovano in <tt>/usr/share/terminfo</tt>, sulle moderne distribuzioni 
di Linux. 

Il database <em>terminfo</em> ha ampiamente sostituito il pi&ugrave;
vecchio <em>termcap</em> ed il completamente obsoleto <em>termlib</em>.
Ci&ograve; normalmente non ha nessuna attinenza con l'installazione dei 
programmi, eccetto quando si ha a che fare con un pacchetto che richiede 
<em>termcap</em>.

La maggior parte delle distribuzioni Linux ora usano <em>terminfo</em>, ma 
ancora conservano le librerie <em>termcap</em> per compatibilit&agrave; con 
le applicazioni legacy (vedere <tt>/etc/termcap</tt>). A volte c'&egrave; 
uno speciale pacchetto di compatibilit&agrave; che &egrave; necessario aver
installato per facilitare l'uso dei binari linkati con termcap. Raramente, 
potrebbe essere necessario togliere il commento da una dichiarazione 
<em>#define termcap</em> in un file sorgente. Controllate i file di 
documentazione appropriati nella vostra distribuzione per informazioni a 
tal riguardo.



<sect>Compatibilit&agrave; all'indietro con i binari a.out
<p>

In rarissimi casi, &egrave; necessario usare binari a.out, o perch&eacute; il
codice sorgente non &egrave; disponibile o perch&eacute;, per una qualche
ragione, non &egrave; possibile compilare nuovi binari ELF dal sorgente.

Come succede, le installazioni ELF hanno quasi sempre un completo
insieme di librerie a.out nella directory <tt>/usr/i486-linuxaout/lib</tt>.
Lo schema di numerazione delle librerie a.out differisce da quello delle
ELF, evitando intelligentemente conflitti che potrebbero creare
confusione. I binari a.out dovrebbero perci&ograve; essere in grado di trovare
le giuste librerie in fase di esecuzione, ma ci&ograve; potrebbe non accadere
sempre.

Notate che il kernel necessita di avere il supporto per a.out, o
direttamente o come modulo caricabile. Potrebbe essere necessario
ricompilare il kernel per abilitare ci&ograve;. Inoltre, alcune distribuzioni
di Linux richiedono l'installazione di uno speciale pacchetto di
compatibilit&agrave;, come <tt>xcompat</tt> di Debian, per eseguire
applicazioni X a.out.

<sect1>Un esempio
<p>

Jerry Smith ha scritto il comodissimo programma <em>xrolodex</em> alcuni
anni fa. Esso usa le librerie Motif, ma fortunatamente &egrave; disponibile
come binario linkato staticamente in formato a.out. Sfortunatamente,
il sorgente necessita di numerosi aggiustamenti per essere ricompilato
usando le librerie <em>lesstif</em>. Ancor pi&ugrave; sfortunatamente, il
binario a.out su di un sistema ELF va in bomba con il seguente messaggio
d'errore.
<tscreen><verb>
xrolodex: can't load library '//lib/libX11.so.3'
No such library
</verb></tscreen>
(Traducendo: non &egrave; possibile caricare la libreria //lib/libX11.so.3;
non c'&egrave; nessuna libreria con quel nome)

Si d&agrave; il caso che ci sia una tale libreria, in
<tt>/usr/i486-linuxaout/lib</tt>, ma xrolodex &egrave; incapace di trovarla in
fase di esecuzione. La soluzione semplice &egrave; di fornire un link
simbolico nella directory <tt>/lib</tt>:

<tt>ln -s /usr/i486-linuxaout/lib/X11.so.3.1.0 libX11.so.3</tt>


Ne viene fuori che &egrave; necessario fornire link simili per le
librerie libXt.so.3 e libc.so.4. Ci&ograve; deve essere fatto come root,
naturalmente. Notate che dovrete essere assolutamente certi di non
sovrascrivere o provocare conflitti di versione con librerie
preesistenti. Fortunatamente, le nuove librerie ELF hanno numeri di
versione pi&ugrave; alti delle pi&ugrave; vecchie a.out, per prevenire ed
impedire proprio tali problemi.

Dopo aver creato i tre link, <em>xrolodex</em> funziona bene.

Il pacchetto <em>xrolodex</em> era originariamente pubblicato su <url
url="http://www.spectro.com/" name="Spectro">, ma sembra che sia sparito
da l&igrave;. Attualmente pu&ograve; essere scaricato da <url
url="http://metalab.unc.edu/pub/Linux/apps/reminder/xrolodex.tar.z"
name="Sunsite"> come file sorgente [512k] in formato <em>tar.Z</em>.



<sect>Risoluzione dei problemi
<p>

Se <em>xmkmf</em> e/o <em>make</em> hanno funzionato senza problemi,
potete passare alla <ref id="finalsteps" name="prossima sezione">.
Tuttavia, nella "vita reale", poche cose vanno bene al primo tentativo.
&Egrave in questi casi che la vostra intraprendenza viene messa alla prova.

<sect1>Errori in fase di link
<p>
<itemize>
<item>Supponiamo che <em>make</em> fallisca con un: <tt>Link error: -lX11:
No such file or directory</tt> (Nessun file o directory con quel nome), 
anche dopo che xmkmf &egrave stato invocato. Ci&ograve; potrebbe significare
che il file <em>Imake</em> non &egrave; stato preparato correttamente.
Controllate che nella prima parte del <em>Makefile</em> ci siano delle righe
tipo:

<tscreen><verb>
LIB=            -L/usr/X11/lib
INCLUDE=        -I/usr/X11/include/X11
LIBS=           -lX11 -lc -lm
</verb></tscreen>

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

</itemize>

<itemize>

<item>Riferimenti non definiti alle funzioni della libreria matematica, 
come il seguente:
<tscreen><verb>
         /tmp/cca011551.o(.text+0x11): undefined reference to `cos'
</verb></tscreen>

La soluzione &egrave; di linkargli esplicitamente la <tt>libreria
matematica</tt>, aggiungendo un <bf>-lm</bf> al flag <em>LIB</em> o
<em>LIBS</em> nel <tt>Makefile</tt> (vedere esempio precedente).

</itemize>



<itemize>

<item>Ancora un'altra cosa da provare se <em>xmkmf</em> fallisce &egrave; 
lo script seguente:
<tscreen><verb>
         make -DUseInstalled -I/usr/X386/lib/X11/config
</verb></tscreen>
Che &egrave; una specie di <em>xmkmf</em> ridotto all'osso.

</itemize>

<itemize>

In rarissimi casi, l'esecuzione di <em>ldconfig</em> come <em>root</em>
potrebbe essere la soluzione:
<tscreen><verb>
</verb></tscreen>

<bf># ldconfig</bf> aggiorna i link simbolici alla libreria condivisa.
<em>Questo potrebbe non essere necessario.</em>

</itemize>

<itemize>

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

</itemize>


<itemize>

<item>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&agrave; 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 
<tt>librerie R5</tt> sono chiamate <tt>libX11.so.3.1.0</tt>, 
<tt>libXaw.so.3.1.0</tt>, e <tt>libXt.so.3.1.0</tt>. Di solito vi servono 
dei link, come <em>libX11.so.3 -> libX11.so.3.1.0</em>. Forse il 
software avr&agrave; bisogno anche di un link del tipo <em>libX11.so ->
libX11.so.3.1.0</em>. Naturalmente, per creare un link "mancante", usate 
il comando <bf>ln -s libX11.so.3.1.0 libX11.so</bf>, <em>come root</em>.

</itemize>




<itemize>

<item>
Alcuni pacchetti esigeranno l'installazione di versioni aggiornate di una o
pi&ugrave; librerie. Per esempio, le versioni 4.x della suite 
<em>StarOffice</em> della StarDivision GmbH erano famose per richiedere 
<tt>libc</tt> in versione 5.4.4 o successiva. Anche il pi&ugrave; recente
<em>StarOffice</em> 5.0 non girer&agrave; nemmeno dopo l'installazione con 
le nuove librerie <tt>glibc 2.1</tt>. Fortunatamente, il pi&ugrave; nuovo
<em>StarOffice</em> 5.1 risolve tali problemi. Se avete una versione di
<em>StarOffice</em> pi&ugrave; vecchia, potreste dover copiare, da root, una 
o pi&ugrave; librerie nelle directory appropriate, rimuovere le vecchie 
librerie, poi ripristinare i link simbolici (controllate l'ultima versione 
dello <tt>StarOffice miniHOWTO</tt> <ref id="traduzioni" name="(tradotto)"> 
per maggiori informazioni su questo argomento).

<bf>Attenzione: Usate molta cautela nel fare ci&ograve;, poich&eacute; potreste
rendere non funzionante il vostro sistema se combinate dei pasticci.</bf>

Potete trovare le librerie pi&ugrave; aggiornate presso <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/libs" name="Sunsite">.

</itemize>

<sect1>Altri problemi
<p>

<itemize>

<item>Uno script <em>Perl</em> o shell installato vi d&agrave; un <tt>No such
file or directory</tt> 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:
<tscreen><verb>
#!/usr/local/bin/perl
</verb></tscreen>
Se infatti <em>Perl</em> &egrave; installato nella vostra directory
<tt>/usr/bin</tt> invece che nella <tt>/usr/local/bin</tt>, allora lo
script non funzioner&agrave;. Ci sono due modi per correggere
questo problema. L'intestazione del file script pu&ograve; essere cambiata in
<tt>#!/usr/bin/perl</tt>, o si pu&ograve; aggiungere un link simbolico alla
giusta directory, <bf>ln -s /usr/bin/perl /usr/local/bin/perl</bf>.

</itemize>

<itemize>

<item>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 <url url="http://www.lesstif.org/" 
name="Lesstif">). Se vi serve Motif per la compilazione di un certo 
pacchetto, ma vi mancano le librerie Motif, pu&ograve essere possibile
ottenere dei <em>binari linkati staticamente</em>. Il linkaggio statico
incorpora le routine di libreria nei binari stessi. Ci&ograve; si traduce in
file binari pi&ugrave; grandi, ma il codice girer&agrave; sui sistemi in cui
mancano le librerie.

<tscreen><verb>
</verb></tscreen>

Quando un pacchetto richiede, per la compilazione, delle librerie non 
presenti sul vostro sistema, ci&ograve provocher&agrave; errori in fase di link
(errori tipo <tt>undefined reference</tt> - riferimento non definito).
Le librerie potrebbero essere del tipo costoso (propriet&agrave; di qualcuno)
o difficili da trovare per qualche altra ragione. In tal caso, 
ottenere un binario <em>linkato staticamente</em> dall'autore del pacchetto, 
o da un gruppo utenti Linux, pu&ograve; essere il modo pi&ugrave; facile per
effettuare delle riparazioni.

</itemize>


<itemize>
Eseguendo uno script <em>configure</em> &egrave; stato creato uno strano
Makefile, uno che sembra non avere nulla a che fare col pacchetto che state
tentando di compilare. Ci&ograve; significa che &egrave; stato eseguito il
<em>configure</em> sbagliato, uno trovato da qualche altra parte nel path.
Lanciate sempre <em>configure</em> come <bf>./configure</bf> per evitare
questo problema.
</itemize>


<itemize>
La maggior parte delle distribuzioni sono passate alle librerie
<tt>libc 6 / glibc 2</tt> dalla pi&ugrave; vecchia <tt>libc 5</tt>. I binari
precompilati che funzionavano con la vecchia libreria potrebbero andare
in bomba se avete aggiornato la libreria. La soluzione &egrave; o di
ricompilare le applicazioni dal sorgente o di ottenere dei nuovi binari
precompilati. Se state aggiornando il vostro sistema a <tt>libc 6</tt> e
riscontrate dei problemi, fate riferimento al <em>Glibc 2 HOWTO</em>
<ref id="traduzioni" name="(tradotto)"> di Eric Green.

<tscreen><verb>
</verb></tscreen>

Notate che ci sono delle piccole incompatibilit&agrave; fra le versioni minori
di <tt>glibc</tt>, cos&igrave; un binario compilato con <tt>glibc 2.1</tt>
potrebbe non funzionare con <tt>glibc 2.0</tt> e vice versa.


</itemize>

<itemize>
A volte &egrave necessario togliere l'opzione <em>-ansi</em> dai flag di
compilazione nel <tt>Makefile</tt>. Ci&ograve; 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).
</itemize>

<itemize>

<item>Alcuni programmi esigono di essere <em>setuid root</em>, per poter
essere eseguiti con <em>privilegi di root</em>. Il comando per effettuare
ci&ograve; &egrave; <bf>chmod u+s nomefile</bf>, <em>come root</em> (osservate
che il programma deve gi&agrave; essere di propriet&agrave; di root). Questo ha
l'effetto di impostare il bit <em>setuid</em> 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&agrave; messaggi di
errore tipo <em>access denied</em> (accesso negato) ad un utente normale, 
sospettate che la causa sia questa.

<P>

<bf>Avvertimento:</bf>
Un programma con <em>setuid</em> impostato come root pu&ograve; porre un 
rischio di sicurezza per il sistema. Il programma gira con privilegi di root 
ed ha cos&igrave; il potenziale di causare danni significativi. Accertatevi 
di sapere cosa fa il programma, guardando il sorgente se possibile, prima
di impostare il bit <em>setuid</em>.

</itemize>


<sect1>Ritocchi e messa a punto
<p>

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


<sect1>Dove trovare maggiore aiuto
<p>

Nella mia esperienza, forse il 25% delle applicazioni supera la
fase di compilazione cos&igrave; com'&egrave;, senza problemi. Un altro 50%,
o gi&ugrave; di l&igrave;, pu&ograve 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 <tt>ELF</tt> e/o <tt>a.out</tt> di questi
potrebbero essere trovati presso <htmlurl url="ftp://metalab.unc.edu"
name="Sunsite"> o presso <htmlurl url="ftp://tsx-11.mit.edu"
name = "TSX-11 archive">. <url url="http://redhat.com" name="Red Hat"> e
<url url="http://www.debian.org" name="Debian"> hanno vasti archivi di binari
preimpacchettati della maggior parte dei pi&ugrave; popolari software per Linux.
Forse l'autore del software pu&ograve; fornire i binari compilati per il
vostro particolare tipo di macchina.


<tt>Notate che se ottenete i binari precompilati, dovrete controllarne la
compatibilit&agrave; con il vostro sistema:</tt>
<itemize>
<item><tt>I binari devono girare sul vostro hardware (i.e., Intel x86).</tt>
<item><tt>I binari devono essere compatibili con il vostro kernel (i.e., 
a.out o ELF).</tt>
<item><tt>Le vostre librerie devono essere aggiornate.</tt>
<item><tt>Il vostro sistema deve avere le appropriate utilit&agrave; di
installazione (rpm o deb)</tt>.
</itemize>

Se tutto il resto non funziona, potete trovare aiuto nei newsgroup
appropriati, come <htmlurl url="news://comp.os.linux.x"
name="comp.os.linux.x"> o <htmlurl url="news://comp.os.linux.development"
name="comp.os.linux.development">.

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





<sect>Conclusioni<label id="finalsteps">
<p>
Leggete la documentazione del pacchetto software per stabilire se certe
variabili d'ambiente hanno bisogno di impostazioni (in <tt>.bashrc</tt>
o <tt>.cshrc</tt>) e se i file <tt>.Xdefaults</tt> e <tt>.Xresources</tt>
hanno bisogno di essere personalizzati.

Potrebbe esserci un file di default per l'applicazione, di solito chiamato
<tt>Xprog.ad</tt> nella distribuzione Xprog originale. Se &egrave; 
cos&igrave;, editate il file Xprog.ad per adattarlo alla vostra macchina, 
poi cambiategli nome (<bf>mv</bf>) in Xprog ed installatelo nella directory
<tt>/usr/lib/X11/app-defaults</tt> <em>come root</em>. Un insuccesso nel
fare ci&ograve; potrebbe far s&igrave; che il software si comporti stranamente 
o addirittura si rifiuti di girare.

La maggior parte dei pacchetti software comprendono una o pi&ugrave; pagine
di manuale preformattate. <em>Come root</em>, copiate il file Xprog.man 
nella directory <tt>/usr/man</tt>, <tt>/usr/local/man</tt>, o
<tt>/usr/X11R6/man</tt> appropriata (<tt>man1</tt> - <tt>man9</tt>), e
cambiategli nome come del caso. Per esempio, se Xprog.man finisce in
/usr/man/man4, dovrebbe essere rinominato Xprog.4 (mv Xprog.man Xprog.4).
Per convenzione, i comandi utente vanno in <tt>man1</tt>, i giochi
in <tt>man6</tt>, ed i pacchetti di amministrazione in <tt>man8</tt>
(vedere la <em>documentazione di man</em> per maggiori dettagli). 
Naturalmente, se vi va, potete discostarvi dalla convenzione, sul 
vostro sistema.

Alcuni, pochi, pacchetti non installeranno i binari nelle appropriate 
directory di sistema, cio&egrave; essi non hanno l'opzione <em>install</em> 
nel <tt>Makefile</tt>. In tal caso, potete installare manualmente i binari
copiandoli nell'appropriata directory di sistema, <tt>/usr/bin</tt>,
<tt>/usr/local/bin</tt> o <tt>/usr/X11R6/bin</tt>, <em>come root</em>, 
naturalmente. Notate che <tt>/usr/local/bin</tt> &egrave; la directory
da preferire per i binari che non fanno parte della distribuzione di base
di Linux.

Alcune o tutte le suddette procedure ,nella maggior parte dei casi, 
dovrebbero essere effettuate automaticamente con un <bf>make install</bf>, 
e forse un <bf>make install.man</bf> o un <bf>make install_man</bf>. Se 
&egrave; cos&igrave;, i file di documentazione <tt>README</tt> o 
<tt>INSTALL</tt> lo specificheranno.


<sect>Primo esempio: Xscrabble
<p>
L'<tt>Xscrabble</tt> di Matt Chapman aveva l'aria di essere un programma
che sarebbe stato interessante avere, poich&eacute; si d&agrave; il caso che
io sia un accanito giocatore di Scrabble<tt>TM</tt>. Lo scaricai, decompressi,
e lo compilai seguendo la procedura nel file README:
<tscreen><verb>
     xmkmf
     make Makefiles
     make includes
     make
</verb></tscreen>

<em>Ovviamente non funzion&ograve;...</em>

<tscreen><verb>
gcc -o xscrab -O2 -O -L/usr/X11R6/lib 
init.o xinit.o misc.o moves.o cmove.o main.o xutils.o mess.o popup.o
widgets.o display.o user.o CircPerc.o
-lXaw -lXmu -lXExExt -lXext -lX11 -lXt -lSM -lICE -lXExExt -lXext -lX11
-lXpm -L../Xc -lXc

BarGraf.o(.text+0xe7): undefined reference to `XtAddConverter'
BarGraf.o(.text+0x29a): undefined reference to `XSetClipMask'
BarGraf.o(.text+0x2ff): undefined reference to `XSetClipRectangles'
BarGraf.o(.text+0x375): undefined reference to `XDrawString'
BarGraf.o(.text+0x3e7): undefined reference to `XDrawLine'
etc.
etc.
etc...
</verb></tscreen>

Indagai su ci&ograve; nel newsgroup <htmlurl url="news://comp.os.linux.x"
name="comp.os.linux.x">, e qualcuno gentilmente mi indic&ograve; che, 
apparentemente, le librerie Xt, Xaw, Xmu, e X11 non erano state trovate
nella fase di link. Hmmm...

C'erano due Makefile principali, e quello nella directory <tt>src</tt>
cattur&ograve; la mia attenzione. Una linea nel Makefile definita LOCAL_LIBS:
LOCAL_LIBS = $(XAWLIB) $(XMULIB) $(XTOOLLIB) $(XLIB). Qui c'erano i
riferimenti alle librerie non trovate dal linker.

Cercando il successivo riferimento a LOCAL_LIBS, vidi alla linea 495 di
quel Makefile:
<tscreen><verb>
      $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LOCAL_LIBS) $(LDLIBS)
$(EXTRA_LOAD_FLAGS)
</verb></tscreen>

Ora, cos'erano queste LDLIBS?
<tscreen><verb>
      LDLIBS = $(LDPOSTLIB) $(THREADS_LIBS) $(SYS_LIBRARIES)
$(EXTRA_LIBRARIES)
</verb></tscreen>

Le SYS_LIBRARIES erano:
<tscreen><verb>
 SYS_LIBRARIES = -lXpm -L../Xc -lXc
</verb></tscreen>
S&igrave;! Le librerie mancanti erano qui.

&Egrave; possibile che il linker avesse bisogno di vedere le LDLIBS prima
delle LOCAL_LIBS...
Cos&igrave;, la prima cosa da provare era di modificare il Makefile invertendo
le $(LOCAL_LIBS) e le $(LDLIBS) alla linea 495, dunque ora si 
dovrebbe leggere:
<tscreen><verb>
        $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LDLIBS) $(LOCAL_LIBS)
$(EXTRA_LOAD_FLAGS)                          ^^^^^^^^^^^^^^^^^^^^^^^
</verb></tscreen>

Provai ad eseguire di nuovo <em>make</em> con i suddetti cambiamenti e, 
guarda un po', stavolta funzion&ograve;. Xscrabble aveva ancora bisogno 
di qualche aggiustamento ed una messa a punto, ovviamente, come cambiare 
nome al dizionario e togliere il commento da qualche statement assert in 
uno dei file sorgenti, ma da allora mi ha fornito svariate ore di 
divertimento.



[Notate che ora &egrave disponibile una nuova versione di Xscrabble in formato
rpm, e questa si installa senza problemi.]




Potete contattare <url url="mailto:matt@belgarath.demon.co.uk" name="Matt
Chapman"> via e-mail, e scaricare <em>Xscrabble</em> dalla sua <url
url="http://www.belgarath.demon.co.uk/programs/index.html" name="home
page">.




<tscreen><verb>
       Scrabble &egrave; un marchio registrato dalla Milton Bradley Co., Inc.
</verb></tscreen>



<sect>Secondo esempio: Xloadimage
<p>
Questo esempio pone un problema pi&ugrave; facile. Il programma
<em>xloadimage</em> sembrava un'utile aggiunta alla mia raccolta di attrezzi
grafici. Ho copiato il file <tt>xloadi41.gz</tt> direttamente dalla directory
sorgente sul CD, allegato all'eccellente libro <ref id="refs"
name="X User Tools">, di Mui e Quercia. Come c'era da aspettarsi,
<em>tar xzvf</em> estrae i file dall'archivio. Il <em>make</em>, per&ograve;,
fornisce un antipatico errore e termina.

<tscreen><verb>
gcc -c -O -fstrength-reduce -finline-functions -fforce-mem
-fforce-addr -DSYSV  -I/usr/X11R6/include
-DSYSPATHFILE=\"/usr/lib/X11/Xloadimage\" mcidas.c

In file included from /usr/include/stdlib.h:32,
                 from image.h:23,
                 from xloadimage.h:15,
                 from mcidas.c:7:
/usr/lib/gcc-lib/i486-linux/2.6.3/include/stddef.h:215:
conflicting types for `wchar_t'
/usr/X11R6/include/X11/Xlib.h:74: previous declaration of
`wchar_t'
make[1]: *** [mcidas.o] Error 1
make[1]: Leaving directory
`/home/thegrendel/tst/xloadimage.4.1'
make: *** [default] Error 2
</verb></tscreen>

Il messaggio d'errore contiene l'indizio essenziale.

Guardando il file <tt>image.h</tt>, linea 23...
<tscreen><verb>
       #include <stdlib.h>
</verb></tscreen>

Aha, da qualche parte nel sorgente per <em>xloadimage</em>,
<em>wchar_t</em> &egrave; stato ridefinito in modo diverso da quanto
specificato nel file include standard, <tt>stdlib.h</tt>. Proviamo
prima a commentare la linea 23 in <tt>image.h</tt>, che forse 
l'<em>include stdlib.h</em>, dopo tutto, non &egrave; necessario.

A questo punto, la fase di compilazione procede senza nessun errore 
fatale. Il pacchetto <em>xloadimage</em> funziona correttamente ora.




<sect>Terzo esempio: Fortune
<p>
Questo esempio richiede qualche conoscenza di programmazione in C. La
maggioranza del software UNIX/Linux &egrave; scritta in C, e imparare almeno
un po' di C sarebbe certamente un bene per chiunque sia seriamente
interessato all'installazione del software.

Il famoso programma <em>fortune</em> mostra una frase umoristica, un
"biscotto della fortuna", ad ogni avvio di Linux. Sfortunatamente (il
gioco di parole &egrave; intenzionale), provare a costruir fortuna su una
distribuzione Red Hat con un kernel 2.0.30 provoca degli errori fatali.
(N.d.T: in inglese "build fortune" significa sia "far fortuna" che
"compilare il programma fortune")

<tscreen><verb>
~/fortune# make all


gcc -O2 -Wall -fomit-frame-pointer -pipe   -c fortune.c -o
fortune.o
fortune.c: In function `add_dir':
fortune.c:551: structure has no member named `d_namlen'
fortune.c:553: structure has no member named `d_namlen'
make[1]: *** [fortune.o] Error 1
make[1]: Leaving directory `/home/thegrendel/for/fortune/fortune'
make: *** [fortune-bin] Error 2
</verb></tscreen>




Guardando <tt>fortune.c</tt>, le linee pertinenti sono queste.

<tscreen><verb>
   if (dirent->d_namlen == 0)
            continue;
        name = copy(dirent->d_name, dirent->d_namlen);
</verb></tscreen>

Ci serve di trovare la struttura <tt>dirent</tt>, ma essa non
&egrave; dichiarata nel file <em>fortune.c</em>, e nemmeno un <bf>grep
dirent</bf> la mostra in nessuno dei file sorgenti. Tuttavia, all'inizio
di <em>fortune.c</em>, c'&egrave; la seguente linea.

<tscreen><verb>
#include <dirent.h>
</verb></tscreen>

Questo sembra essere un file include per la libreria di sistema, perci&ograve;,
il posto pi&ugrave; logico dove cercare <em>dirent.h</em> &egrave; in
<em>/usr/include</em>. Effettivamente esiste un file <em>dirent.h</em> in
<em>/usr/include</em>, ma quel file non contiene la dichiarazione della
struttura <tt>dirent</tt>. C'&egrave;, per&ograve;, un riferimento ad un altro
file <em>dirent.h</em>.

<tscreen><verb>
#include <linux/dirent.h>
</verb></tscreen>


Alla fine, andando in <em>/usr/include/linux/dirent.h</em>, troviamo
la dichiarazione della struttura che ci serve.

<tscreen><verb>
struct dirent {
        long            d_ino;
        __kernel_off_t  d_off;
        unsigned short  d_reclen;
        char            d_name[256]; /* We must not include
limits.h! */
};
</verb></tscreen>

Poco ma sicuro, la dichiarazione della struttura non contiene nessun
<em>d_namelen</em>, ma ci sono un paio di "candidati" come suo
equivalente. Il pi&ugrave; probabile di essi &egrave; <em>d_reclen</em>,
poich&eacute; questo membro della struttura probabilmente rappresenta la
lunghezza di qualcosa ed &egrave; uno short integer. L'altra possibilit&agrave;,
<em>d_ino</em>, potrebbe essere un numero di inode, a giudicare dal suo nome
e tipo. A quanto pare, stiamo probabilmente trattando con una struttura di
"registrazione delle directory", e questi elementi rappresentano gli attributi
di un file, il suo nome, il suo inode, e la sua lunghezza (in blocchi).
Ci&ograve; sembrerebbe convalidare la nostra scelta.

Editiamo il file <tt>fortune.c</tt> e cambiamo i due riferimenti alle
linee 551 e 553 da <em>d_namelen</em> a <em>d_reclen</em>. Proviamo di
nuovo un <em>make all</em>. <bf>Successo.</bf> La compilazione finisce senza
errori. Ora possiamo prenderci i nostri "brividi a buon mercato" da fortune.


<sect>Quarto esempio: Hearts
<p>

Ecco il vecchio canuto gioco Hearts, scritto per i sistemi UNIX da Bob
Ankeney negli anni '80, rivisto nel 1992 da Mike Yang, ed attualmente
mantenuto da <url url="mailto:badger@phylo.life.uiuc.edu" name="Jonathan
Badger">. Il suo predecessore era un ancor pi&ugrave; vecchio programma Pascal
di Don Backus della Oregon Software, poi aggiornato da Jeff Hemmerling.
Originariamente pensato come client per pi&ugrave giocatori, funziona bene
anche per un solo giocatore contro avversari gestiti dal computer. La grafica
&egrave; bella, bench&eacute; il gioco manchi di caratteristiche
pi&ugrave; sofisticate e i giocatori computerizzati non siano molto forti.
Nonostante tutto, sembra essere il solo Hearts decente disponibile per
macchine UNIX e Linux ancora oggi.

A causa della sua stirpe ed et&agrave;, questo pacchetto
&egrave; particolarmente difficile da compilare su di un sistema Linux.
Richiede la soluzione di una lunga e sconcertante serie di puzzle.
&Egrave; un esercizio di pazienza e determinazione.

<em>Prima di iniziare, accertatevi di avere le librerie <tt>motif</tt> o
le <tt>lesstif</tt> installate.</em>

<itemize>
<item><bf></bf>
</itemize>

<bf>xmkmf</bf>

<bf>make</bf>

<tscreen><verb>
client.c: In function `read_card':
client.c:430: `_tty' undeclared (first use in this function)
client.c:430: (Each undeclared identifier is reported only once
client.c:430: for each function it appears in.)
client.c: In function `scan':
client.c:685: `_tty' undeclared (first use in this function)
make: *** [client.o] Error 1
</verb></tscreen>


Questi sono i colpevoli nel file <tt>client.c</tt>:

<tscreen><verb>
#ifndef SYSV
        (buf[2] != _tty.sg_erase) && (buf[2] != _tty.sg_kill)) {
 #else
        (buf[2] != CERASE) && (buf[2] != CKILL)) {
#endif
</verb></tscreen>




<itemize>
<item><bf></bf>
</itemize>
In <tt>client.c</tt>, aggiungiamo
<tscreen><verb>
#define SYSV
</verb></tscreen>
alla linea 39. Ci&ograve; bypasser&agrave; il riferimento a <em>_tty</em>.

<bf>make</bf>

<tscreen><verb>
client.c:41: sys/termio.h: No such file or directory
make: *** [client.o] Error 1
</verb></tscreen>


<itemize>
<item><bf></bf>
</itemize>

Il file include <tt>termio.h</tt> &egrave; nella directory <tt>/usr/include</tt>
su di un sistema Linux, invece che nella <tt>/usr/include/sys</tt>,
come era sulle vecchie macchine UNIX. Perci&ograve;, cambiamo la linea 41 di
<tt>client.c</tt> da
<tscreen><verb>
#include <sys/termio.h>
</verb></tscreen>
a
<tscreen><verb>
#include <termio.h>
</verb></tscreen>

<bf>make</bf>

<tscreen><verb>
gcc -o hearts -g      -L/usr/X11R6/lib client.o hearts.o select.o connect.o
sockio.o start_dist.o  -lcurses -ltermlib       
/usr/bin/ld: cannot open -ltermlib: No such file or directory
collect2: ld returned 1 exit status
make: *** [hearts] Error 1
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

Le moderne distribuzioni Linux usano il database <em>terminfo</em> e/o
<em>termcap</em>, piuttosto che l'obsoleto <em>termlib</em>.

Editiamo il <tt>Makefile</tt>.

Linea 655:
<tscreen><verb>
CURSES_LIBRARIES = -lcurses -ltermlib
</verb></tscreen>

cambiamola in:
<tscreen><verb>
CURSES_LIBRARIES = -lcurses -ltermcap
</verb></tscreen>


<bf>make</bf>

<tscreen><verb>
gcc -o xmhearts -g      -L/usr/X11R6/lib xmclient.o hearts.o select.o
connect.o sockio.o start_dist.o gfx.o  -lXm_s -lXt -lSM -lICE -lXext -lX11
-lPW       
/usr/bin/ld: cannot open -lXm_s: No such file or directory
collect2: ld returned 1 exit status
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

La principale libreria <em>lesstif</em> &egrave; <tt>libXm</tt>,
piuttosto che <tt>libXm_s</tt>. Quindi, editiamo il <tt>Makefile</tt>.

Nella linea 653:
<tscreen><verb>
XMLIB = -lXm_s $(XTOOLLIB) $(XLIB) -lPW
</verb></tscreen>

cambia in:
<tscreen><verb>
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW
</verb></tscreen>


<bf>make</bf>

<tscreen><verb>
gcc -o xmhearts -g      -L/usr/X11R6/lib xmclient.o hearts.o select.o
connect.o sockio.o start_dist.o gfx.o  -lXm -lXt -lSM -lICE -lXext -lX11 -lPW       
/usr/bin/ld: cannot open -lPW: No such file or directory
collect2: ld returned 1 exit status
make: *** [xmhearts] Error 1
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

Raduniamo i soliti sospetti.

Non c'&egrave; nessuna libreria <tt>PW</tt>. Editiamo il <tt>Makefile</tt>.

Linea 653:
<tscreen><verb>
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW
</verb></tscreen>

cambia in:
<tscreen><verb>
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPEX5
</verb></tscreen>
(La libreria <tt>PEX5</tt> &egrave; quella pi&ugrave; simile alla <tt>PW</tt>.)



<bf>make</bf>


<tscreen><verb>
rm -f xmhearts
gcc -o xmhearts -g      -L/usr/X11R6/lib xmclient.o hearts.o select.o
connect.o sockio.o start_dist.o gfx.o  -lXm -lXt -lSM -lICE -lXext -lX11 -lPEX5       
</verb></tscreen>

Il <tt>make</tt> finalmente funziona (hurra!)



<itemize>
<item><bf></bf>
</itemize>

<em>Installazione:</em>

Come root,

<tscreen><verb>
[root@localhost hearts]# make install
install -c -s  hearts /usr/X11R6/bin/hearts
install -c -s  xmhearts /usr/X11R6/bin/xmhearts
install -c -s  xawhearts /usr/X11R6/bin/xawhearts
install in . done
</verb></tscreen>





<itemize>
<item><bf></bf>
</itemize>

<em>Esecuzione di prova:</em>

<bf>rehash</bf>

(Stiamo eseguendo la shell <tt>tcsh</tt>.)

<bf>xmhearts</bf>

<tscreen><verb>
localhost:~/% xmhearts
Can't invoke distributor!
</verb></tscreen>



<itemize>
<item><bf></bf>
</itemize>

Dal file <tt>README</tt> nel pacchetto <tt>hearts</tt>:

<tscreen><verb>
     Put heartsd, hearts_dist, and hearts.instr in the HEARTSLIB
     directory defined in local.h and make them world-accessible.
</verb></tscreen>
(Traducendo: Mettete Heartsd, hearts_dist, e hearts.instr nella
directory HEARTSLIB definita in local.h e rendeteli accessibili
a chiunque)

    
Dal file <tt>local.h</tt>:

<tscreen><verb>
/* where the distributor, dealer and instructions live */

#define HEARTSLIB "/usr/local/lib/hearts"
</verb></tscreen>

Questo &egrave; un classico caso: RTFM (leggete il fottuto manuale).


Come <em>root</em>,

<bf>cd /usr/local/lib</bf>

<bf>mkdir hearts</bf>

<bf>cd !$</bf>

Copiamo i file di <tt>distributor</tt> in questa directory.

<bf>cp /home/username/hearts/heartsd .</bf>

<bf>cp /home/username/hearts/hearts_dist .</bf>

<bf>cp /home/username/hearts/hearts.instr .</bf>



<itemize>
<item><bf></bf>
</itemize>

<em>Lanciamo un'altra esecuzione di prova.</em>

<bf>xmhearts</bf>

Qualche volta funziona, ma il pi&ugrave; delle volte si pianta con un
messaggio <tt>dealer died!</tt>.



<itemize>
<item><bf></bf>
</itemize>

Il "distributor" e il "dealer" esaminano le porte hardware. Dovremmo 
perci&ograve; sospettare che quei programmi abbiano bisogno dei privilegi 
di root.

Proviamo, come <em>root</em>,

<bf>chmod u+s /usr/local/lib/heartsd</bf>

<bf>chmod u+s /usr/local/lib/hearts_dist</bf>

(Osserviamo che, come discusso precedentemente, i binari <em>suid</em>
possono creare dei buchi di sicurezza.)

<bf>xmhearts</bf>


<em>Alla fine funziona!</em>


<tt><em>Hearts</em> &egrave; disponibile da <htmlurl
url="ftp://metalab.unc.edu/pub/Linux/games/multiplayer/hearts.tgz"
name="Sunsite">.</tt>


<sect>Quinto esempio: XmDipmon
<p>
 
<tscreen><verb>
Bullwinkle: Hey Rocky, guarda, tiro fuori un coniglio dal cappello.
Rocky:      Ma quel trucco non funziona mai.
Bullwinkle: Questa volta s&igrave;.
            Voil&agrave;!
	    Beh, ci sono andato vicino.
Rocky:      Ed ora &egrave; il momento di un altro effetto speciale.
            --- "Rocky e i suoi amici"
</verb></tscreen>
 	     
XmDipmon &egrave; un'elegante applicazioncina che mostra un bottone 
indicante lo stato di una connessione Internet. Lampeggia e suona quando
la connessione si interrompe, come troppo spesso accade nelle linee 
telefoniche di campagna. Sfortunatamente XmDipmon funziona solo con 
<em>dip</em>, il che lo rende inutile per tutti quelli, la maggioranza,
che usano <em>chat</em> per collegarsi.

Compilare XmDipmon non &egrave; un problema. XmDipmon si linka con le
librerie <em>Motif</em>, ma pu&ograve; essere compilato, e funziona bene,
anche con le <em>Lesstif</em>. La sfida &egrave; di modificare il pacchetto
per farlo funzionare con <em>chat</em>. Ci&ograve; in pratica richiede di
armeggiare con il codice sorgente ed &egrave; quindi necessario avere
delle conoscenze di programmazione.
 
 
 
<tscreen><verb>
        "Quando xmdipmon parte, cerca un file chiamato /etc/dip.pid
         (potete fargli cercare un altro file usando l'opzione -pidfile
         dalla riga di comando). Tale file contiente il PID del demone
         dip (dip stesso si pone in modo demone, dopo che ha stabilito 
         una connessione)."
                       --- dal file README di XmDipmon
</verb></tscreen>	 
 
 
Usando l'opzione <em>-pidfile</em>, il programma pu&ograve; essere
indotto, al suo avvio, a cercare un altro file, uno che esista solo
dopo che un login con <em>chat</em> &egrave; stato effettuato con successo. 
Il candidato pi&ugrave; ovvio &egrave; il file di lock del modem. Potremmo 
quindi provare a lanciare il programma con <bf>xmdipmon -pidfile 
/var/lock/LCK..ttyS3</bf> (assumendo che il modem sia sulla porta com
numero 4, ttyS3). Comunque cos&igrave; si risolve solo una parte del
problema. Il programma osserva continuamente il <em>demone dip</em>
e dobbiamo invece fare in modo che controlli un processo che sia
associato a <em>chat</em> o a <em>ppp</em>.

C'&egrave; un solo file sorgente e fortunatamente &egrave; ben commentato.
Scorrendo il file <tt>xmdipmon.c</tt> troviamo la funzione 
<em>getProcFile</em>, la cui descrizione, all'inizio, riporta quanto segue:

<tscreen><verb>
/*****
* Name:                 getProcFile
* Return Type:  Boolean
* Description:  tries to open the /proc entry as read from the dip pid file.
<snip>
*****/
</verb></tscreen>

(Traducendo la descrizione: prova ad aprire l'elemento di /proc secondo quanto 
letto dal file pid di dip)

Siamo sulla pista giusta. Guardando nel corpo della funzione...
 
<tscreen><verb>
			/* we watch the status of the real dip deamon */
			sprintf(buf, "/proc/%i/status", pid);
			procfile = (String)XtMalloc(strlen(buf)*sizeof(char)+1);
			strcpy(procfile, buf);
			procfile[strlen(buf)] = '\0';
</verb></tscreen>

Il colpevole &egrave; la linea 2383:
<tscreen><verb>
			sprintf(buf, "/proc/%i/status", pid);
			              ^^^^^^^^^^^^^^^^^^^^^
</verb></tscreen>

Questo controlla se il processo demone dip &egrave; in esecuzione. Quindi,
come possiamo cambiarlo in modo che controlli il demone pppd?

Guardando sulla pagina di manuale di <em>pppd</em>:
<tscreen><verb>
FILES
     /var/run/pppn.pid (BSD o Linux), /etc/ppp/pppn.pid (altri)
           Identificatore del processo (Process-ID) di pppd sull'unit&agrave;
           d'interfaccia n di ppp.
</verb></tscreen>
 
Cambiamo la linea 2383 di <tt>xmdipmon.c</tt> in:
<tscreen><verb>
			sprintf(buf, "/var/run/ppp0.pid" );
</verb></tscreen>

Ricompiliamo il pacchetto cos&igrave; modificato. Nessun problema con la
compilazione. Ora proviamolo con il nuovo argomento della riga di comando.
Funziona che &egrave; un incanto. Il bottoncino blu indica quando &egrave; 
stata stabilita una connessione <tt>ppp</tt> con l'ISP e lampeggia e suona
quando la connessione si interrompe. Ora abbiamo un monitor per 
<em>chat</em> pienamente funzionante.


XmDipmon pu&ograve; essere scaricato da <htmlurl
url="http://www.xs4all.nl/~ripley/RSD/linux.html" 
name="Ripley Linux Tools">.



<sect>Dove trovare archivi sorgente
<p>
Ora che siete ansiosi di usare le conoscenze appena
acquisite, per aggiungere delle utilit&agrave; ed altre chicche
al vostro sistema, potete trovarle online alla
<url url="http://www.redhat.com/linux-info/linux-app-list/linapps.html"
name="Linux Applications and Utilities Page">, o in una
delle raccolte su CD ROM, a prezzo molto ragionevole, di
<url url="http://www.redhat.com/" name="Red Hat">,
<url url="http://www.infomagic.com" name="InfoMagic">,
<url url="http://www.lsl.com" name="Linux Systems Labs">,
<url url="http://www.cheapbytes.com" name="Cheap Bytes">, e altri.


Un vasto magazzino di codice sorgente &egrave; <htmlurl
url="ftp://ftp.vix.com/pub/usenet/comp.sources.unix/" name="comp sources
UNIX archive">.

Molto codice sorgente UNIX viene pubblicato nel newsgroup 
<htmlurl url="news://alt.sources" name="alt.sources">. Se state
cercando particolari pacchetti di codice sorgente, potete chiedere
sullo specifico newsgroup <htmlurl url="news://alt.sources.wanted"
name="alt.sources.wanted">.
Un altro buon posto dove cercare &egrave; il newsgroup <htmlurl
url="news://comp.os.linux.announce" name="comp.os.linux.announce">.
Per entrare nella mailing list <htmlurl
url="mailto:unix-sources@pa.dec.com" name="Unix sources">, mandate alla
stessa un messaggio <em>subscribe</em>.

Gli archivi del newsgroup <htmlurl url="news://alt.sources"
name="alt.sources"> si trovano presso i seguenti siti ftp:

<itemize>
<item><htmlurl url="ftp://ftp.sterling.com/usenet/alt.sources/"
name="ftp.sterling.com/usenet/alt.sources/">
<item><htmlurl
url="ftp://wuarchive.wustl.edu/usenet/alt.sources/articles"
name="wuarchive.wustl.edu/usenet/alt.sources/articles">
<item><htmlurl
url="ftp://src.doc.ic.ac.uk/usenet/alt.sources/articles"
name="src.doc.ic.ac.uk/usenet/alt.sources/articles">

</itemize>



<sect>Conclusioni
<p>
Riassumendo, la perseveranza fa tutta la differenza (e un'alta soglia alla
frustrazione certamente aiuta). Come in tutti gli sforzi, imparare dagli
errori &egrave; criticamente importante. Ogni passo falso, ogni fallimento,
contribuisce alla costruzione della conoscenza che conduce alla
padronanza dell'<bf>arte della compilazione del software</bf>.


<sect>Riferimenti e ulteriori letture<label id="refs">
<p>

<tscreen><verb>
BORLAND C++ TOOLS AND UTILITIES GUIDE, Borland International, 1992,
pp. 9-42.
[Uno dei manuali distribuiti col Borland C++, ver. 3.1. D&agrave; una
abbastanza buona introduzione alla sintassi e ai concetti di make,
usando l'implementazione limitata al DOS della Borland.]

DuBois, Paul: SOFTWARE PORTABILITY WITH IMAKE, O'Reilly and Associates,
1996, ISBN 1-56592-226-3.
[&Egrave; ritenuto il riferimento definitivo per imake, sebbene non lo
avevo a disposizione durante la scrittura di questo articolo.]

Frisch, Aeleen: ESSENTIAL SYSTEM ADMINISTRATION (2nd ed.), O'Reilly and
Associates, 1995, ISBN 1-56592-127-5.
[Questo, altrimenti ottimo, manuale per amministratori di sistema tratta 
solo in modo sommario la compilazione del software.]

Hekman, Jessica: LINUX IN A NUTSHELL, O'Reilly and Associates, 1997, ISBN
1-56592-167-4.
[Un buon riferimento globale ai comandi di Linux.]

Lehey, Greg: PORTING UNIX SOFTWARE, O'Reilly and Associates, 1995, ISBN
1-56592-126-7.

Mayer, Herbert G.: ADVANCED C PROGRAMMING ON THE IBM PC, Windcrest Books,
1989, ISBN 0-8306-9363-7.
[Un libro zeppo di idee per programmatori C medi ed esperti. Superba
trattazione degli algoritmi, ricercatezza di linguaggio e anche
divertimento. Sfortunatamente non viene pi&ugrave; stampato.]

Mui, Linda and Valerie Quercia: X USER TOOLS, O'Reilly and Associates,
1994, ISBN 1-56592-019-8, pp. 734-760.

Oram, Andrew and Steve Talbott: MANAGING PROJECTS WITH MAKE, O'Reilly
and Associates, 1991, ISBN 0-937175-90-0.

Peek, Jerry and Tim O'Reilly and Mike Loukides: UNIX POWER TOOLS,
O'Reilly and Associates / Random House, 1997, ISBN 1-56592-260-3.
[Una meravigliosa fonte di idee, e tonnellate di utilit&agrave; che potete
compilare dal codice sorgente, usando i metodi discussi in questo
articolo.]

Stallman, Richard M. and Roland McGrath: GNU MAKE, Free Software
Foundation, 1995, ISBN 1-882114-78-7.
[Da leggere]

Waite, Mitchell, Stephen Prata, and Donald Martin: C PRIMER PLUS, Waite Group 
Press, ISBN 0-672-22090-3,.
[Probabilmente la miglior introduzione alla programmazione in C. Vasta
copertura per un "primo libro". Sono ora disponibili nuove edizioni.]

Welsh, Matt and Lar Kaufman: RUNNING LINUX, O'Reilly and Associates,
1996, ISBN 1-56592-151-8.
[Tuttora il miglior riferimento globale per Linux, sebbene manchi
di profondit&agrave; in alcune aree.]


Le pagine di manuale di dpkg, gcc, gzip, imake, ldconfig, ldd, make, nm,
patch, rpm, shar, strip, tar, termcap, terminfo, e xmkmf.


Il BZIP2 HOWTO (tradotto), di David Fetter.

Il Glibc2 HOWTO (tradotto), di Eric Green

Il LINUX ELF HOWTO (tradotto), di Daniel Barlow.

L'RPM HOWTO, di Donnie Barnes.

Lo StarOffice miniHOWTO, di Matthew Borowski.

</verb></tscreen>

[Questi HOWTO dovrebbero trovarsi nella directory <tt>/usr/doc/HOWTO</tt> o
nella <tt>/usr/doc/HOWTO/mini</tt> sul vostro sistema. Versioni aggiornate
sono disponibili in formato testo, HTML e SGML nel <url
url="http://metalab.unc.edu/LDP/HOWTO" name="sito LDP">, e di solito
nei siti dei rispettivi autori.]

<label id="traduzioni">
__________________

<bf>Traduzioni</bf>: Per la versione in italiano degli HOWTO con 
l'indicazione "(tradotto)" vedere: <htmlurl url="http://www.pluto.linux.it/ildp/HOWTO/HOWTO-INDEX-3.html"
name="www.pluto.linux.it/ildp/HOWTO/HOWTO-INDEX-3.html">.
Per altra documentazione su Linux <em>in italiano</em>, compresi eventuali
HOWTO e/o mini-HOWTO citati ma al momento non ancora tradotti, si veda il 
<url url="http://www.pluto.linux.it/ildp/index.html" name="sito ILDP">.


<sect>Crediti
<p>

L'autore di questo HOWTO desidera ringraziare le seguenti persone per gli
utili suggerimenti, le correzioni e l'incoraggiamento.

<itemize>
<item>R. Brock Lynn
<item>Michael Jenner
<item>Fabrizio Stefani
</itemize>

Gloria va anche a quelle brave persone che hanno tradotto questo HOWTO in 
italiano e giapponese.

E naturalmente, ringraziamenti, lodi, benedizioni e osanna a Greg Hankins e 
Tim Bynum del <url url="http://metalab.unc.edu/LDP/" 
name="Linux Documentation Project">.

</article>