Building and Installing Software Packages for Linux
Mendel Cooper <mailto:
[email protected]> ---
http://personal.riverusers.com/~thegrendel/
v1.91, 27 luglio 1999
- Compilazione ed installazione di pacchetti software per Linux -
Questa � un'ampia guida per compilare ed installare "generiche" dis�
tribuzioni di software UNIX sotto Linux. Vengono inoltre discussi i
formati binari preimpacchettati "rpm" e "deb". Traduzione di Fabrizio
Stefani, 23 settembre 1999.
1. Introduzione
Parecchi pacchetti software per i vari dialetti di UNIX e Linux sono
dati come archivi compressi di file sorgenti. Lo stesso pacchetto pu�
essere "compilato" per girare su differenti macchine fissate, e ci�
risparmia l'autore del software dal dover produrre versioni multiple.
Una singola versione di un pacchetto software pu� cos� 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� della effettiva "compilazione" ed
installazione del software sull'utente finale, l'�amministratore di
sistema� de facto, il tizio seduto alla tastiera -- voi. Fatevi
coraggio, comunque, il processo non � poi cos� terrificante o
misterioso come sembra, come dimostrer� questa guida.
2. Spacchettare i file
Avete scaricato o vi siete procurati in altro modo un pacchetto
software. Molto probabilmente � archiviato (in formato tar) e
compresso (in formato gzip), e quindi il nome del file terminer� con
.tar.gz o .tgz (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 gunzip) e spacchettatelo (con tar). Il
comando appropriato per farlo � tar xzvf nomefile, dove nomefile � il
nome del file, ovviamente. Il processo di dearchiviazione generalmente
installer� i file appropriati nelle sottodirectory che avr� creato.
Notate che se il nome del pacchetto ha suffisso .Z, la procedura su
esposta sar� ancora buona, sebbene funzioni anche eseguire uncompress,
seguito da tar xvf. Potete vedere un'anteprima di tale processo con
tar tzvf nomefile, che elenca i file contenuti nell'archivio senza in
effetti estrarli.
Il suddetto metodo per spacchettare i pacchetti tar � equivalente ad
uno o l'altro dei seguenti:
� gzip -cd nomefile | tar xvf -
� gunzip -c nomefile | tar xvf -
(Il '-' forza il comando tar a prendere il suo input dallo stdin.)
I file sorgenti nel nuovo formato bzip2 (.bz2) possono essere estratti
con un bzip2 -cd nomefile | tar xvf -, o, pi� semplicemente, con un
tar xyvf nomefile, sempre che tar sia stato opportunamente corretto
con l'apposita patch (riferirsi al Bzip2.HOWTO ``(tradotto)'' per i
dettagli). La distribuzione Linux di Debian usa una diversa patch per
tar, scritta da Hiroshi Takekawa, che, in quella particolare versione
di tar, usa le opzioni -I, --bzip2, --bunzip2.
[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 /, /usr/src, o /opt, 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 README e/o Install, se presenti, ed
editate i file di configurazione e/o i Makefile come necessario,
consistentemente con le istruzioni di installazione. Osservate che di
solito non si dovrebbe modificare il file Imake, poich� ci� potrebbe
avere conseguenze impreviste. La maggior parte dei pacchetti
permettono di automatizzare questo processo eseguendo make install per
mettere i binari nelle appropriate aree di sistema.
� Potreste incontrare file shar, o archivi shell, specialmente sui
newsgroup riguardanti il codice sorgente in Internet. Questi
vengono ancora usati perch� sono in formato testo, e ci� permette
ai moderatori dei newsgroup di consultarli e respingere quelli
inadatti. Essi possono essere spacchettati col comando unshar
nomefile.shar. Altrimenti la procedura per trattarli � la stessa
dei pacchetti tar.
� Alcuni archivi sorgente sono stati manipolati usando utilit� di
compressione non standard DOS, Mac o anche Amiga, tipo zip, arc,
lha, arj, zoo, rar,e shk. Fortunatamente, Sunsite
<
http://metalab.unc.edu> e altri posti hanno delle utilit� di
decompressione per Linux che possono trattare molti o tutti tali
formati.
Occasionalmente, potrebbe essere necessario aggiungere delle
correzioni per dei bug o aggiornare i file sorgenti estratti da un
archivio usando un file patch o diff che elenca le modifiche. I file
di documentazione e/o README vi informeranno se ci� � necessario. La
normale sintassi per invocare la potente utilit� di patch di Larry
Wall � patch < patchfile.
Ora potete procedere alla fase di compilazione del processo.
3. Usare make
Il Makefile � la chiave del processo di compilazione. Nella sua forma
pi� semplice, un Makefile � uno script per la compilazione, o
building, dei "binari", le parti eseguibili di un pacchetto. Il
Makefile pu� anche fornire un mezzo per aggiornare un pacchetto
software senza dover ricompilare ogni singolo file sorgente in esso,
ma questa � un'altra storia (o un altro articolo).
Ad un certo punto, il Makefile lancia cc o gcc. Questo in realt� � 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 make di solito richiede solo di battere make. Ci�,
generalmente, serve a compilare tutti i file eseguibili necessari per
il pacchetto in questione. Tuttavia, make pu� svolgere anche altri
compiti, come installare i file nelle loro directory appropriate (make
install) e rimuovere i file oggetto stantii (make clean). L'esecuzione
di make -n permette di vedere un'anteprima del processo di
compilazione, poich� stampa tutti i comandi che sarebbero attivati da
un make, ma senza in effetti eseguirli.
Solo i software pi� semplici usano un Makefile generico. Le
installazioni pi� complesse richiedono un Makefile su misura secondo
la posizione delle librerie, dei file include e delle risorse sulla
vostra specifica macchina. Questo, in particolare, � il caso che si ha
quando durante il processo di compilazione servono le librerie X11 per
l'installazione. Imake e xmkmf adempiono questo compito.
Un Imakefile �, per citare la pagina di manuale, un "prototipo" di
Makefile. L'utilit� imake costruisce un Makefile adatto al vostro
sistema dall'Imakefile. Nella maggior parte dei casi, tuttavia,
preferirete eseguire xmkmf, 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, � presente un file Imake nella directory base, � un chiaro
segno che dovrebbe essere eseguito xmkmf). Leggere le pagine di
manuale di Imake e xmkmf per una pi� dettagliata analisi della
procedura.
� bene essere consapevoli che xmkmf e make potrebbero dover essere
invocati come root, specialmente nel fare un make install per spostare
i binari sulle directory /usr/bin o /usr/local/bin. Usare make come
utente normale, senza privilegi di root, porter� probabilmente a dei
messaggi d'errore tipo write access denied (accesso in scrittura
negato), perch� 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, xmkmf usa il file Imake per costruire il
Makefile appropriato per il vostro sistema. Sarete soliti invocare
xmkmf con l'argomento -a, per effettuare automaticamente make
Makefiles, make includes e make depend. Ci� imposta le variabili e
definisce le posizioni delle librerie per il compilatore ed il linker.
A volte, non ci sar� il file Imake, ci sar� invece uno script INSTALL
o configure, che dovrebbe essere invocato come ./configure per
assicurarsi che venga chiamato il giusto script configure. Nella
maggior parte dei casi, il file README incluso con la distribuzione
spiegher� la procedura di installazione.
� di solito una buona idea guardare dentro il Makefile che xmkmf, o
uno degli script di installazione, costruiscono. Il Makefile sar� 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, make install.
Solitamente, le directory per i binari del sistema sulle moderne
distribuzioni Linux sono /usr/bin, /usr/X11R6/bin, e /usr/local/bin.
La directory da preferire per i nuovi pacchetti � /usr/local/bin,
poich� 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 /opt o in un'altra directory
sconosciuta. Ci�, naturalmente, causer� un errore di installazione se
la directory in questione non esiste. Il modo pi� semplice per
risolvere questo problema � quello di creare, come root, una directory
/opt, lasciare che il pacchetto vi si installi, e poi aggiungere tale
directory alla variabile d'ambiente PATH. Oppure, potete creare dei
link simbolici alla directory /usr/local/bin.
La procedura di installazione generale sar� quindi:
� Leggere il file README ed altri file di documentazione appropriati.
� Eseguire xmkmf -a, o lo script INSTALL o configure.
� Controllare il Makefile.
� Se necessario, eseguire make clean, make Makefiles, make includes,
e make depend.
� Eseguire make.
� Controllare i permessi.
� Se necessario, eseguire make install.
Note:
� Normalmente non si compilano i pacchetti come root. L'effettuare un
su a root � necessario solo per installare i binari compilati nelle
directory di sistema.
� Una volta che avete preso confidenza con make e col suo uso,
potreste volere che vengano aggiunte nel Makefile standard incluso
nel (o creato col) pacchetto che state installando delle opzioni
di ottimizzazione aggiuntive. Alcune di tali opzioni, le pi� usate,
sono -O2, -fomit-frame-pointer, -funroll-loops e -mpentium (se
usate un processore Pentium). Siate cauti e fatevi guidare dal buon
senso quando modificate un Makefile!
� Dopo che make ha creato i binari, potreste voler usare strip su
essi. Il comando strip elimina dai file binari le informazioni per
il debugging simbolico e ne riduce la dimensione, spesso
drasticamente. Ovviamente ci� disabiliter� il debugging.
� Il Pack Distribution Project <
http://sunsite.auc.dk/pack/> 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 directory di
raccolta separate. Questi archivi sono degli ordinari pacchetti
tar, ma si installano nelle directory /coll e /pack. Potreste
dover scaricare il Pack-Collection dal suddetto sito qualora vi
capiti di imbattervi in una di tali distribuzioni.
4. Binari preimpacchettati
4.1. Cosa c'� che non va negli rpm?
La compilazione e l'installazione manuale dei pacchetti dal sorgente �
un compito apparentemente cos� spaventoso per alcuni utenti Linux che
essi hanno abbracciato i popolari formati di pacchetti rpm e deb, o il
pi� recente Stampede slp. Sebbene possa essere vero che
l'installazione di un rpm di solito procede tanto facilmente e tanto
velocemente quanto l'installazione del software di un certo altro noto
sistema operativo, � 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 rpm
corrente � 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 rpm o un deb. Alcuni pacchetti meno
popolari potrebbero non essere mai convertiti in rpm.
Secondo, il pacchetto tar potrebbe facilmente essere pi� completo,
avere pi� opzioni, e prestarsi meglio ad una personalizzazione ed una
messa a punto. La versione binaria rpm potrebbe non avere alcune delle
funzionalit� della versione completa. Gli rpm 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 rpm --recompile nomepacchetto.rpm oppure
rpm --rebuild nomepacchetto.rpm.
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 rpm o un deb 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. � molto pi� conveniente avere
il sorgente nell'archivio da cui si stanno compilando i binari,
piuttosto che in un differente pacchetto rpm.
L'installazione di un pacchetto rpm non � necessariamente una
bazzecola. Se c'� un conflitto di dipendenza, l'installazione dell'rpm
fallir�. L'rpm 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 rpm spesso falliscono per le stesse ragioni per cui lo fanno
quelle dei pacchetti tar.
Dovete installare gli rpm e i deb come root, per avere i necessari
permessi di scrittura, e ci� apre un buco di sicurezza potenzialmente
serio, poich� potreste inavvertitamente massacrare i binari di sistema
e le librerie, o anche installare un cavallo di Troia che potrebbe
liberare il caos sul vostro sistema. � quindi importante ottenere
pacchetti rpm e deb da una "fonte fidata". In ogni caso, dovreste
eseguire una 'verifica della firma' (rispetto ad un codice di
controllo MD5) sul pacchetto, rpm --checksig nomepacchetto.rpm, prima
di installarlo. Allo stesso modo � fortemente raccomandata
l'esecuzione di rpm -K --nopgp nomepacchetto.rpm. I comandi
corrispondenti per i pacchetti deb sono dpkg -I | --info
nomepacchetto.deb e dpkg -e | --control nomepacchetto.deb.
� rpm --checksig gnucash-1.1.23-4.i386.rpm
gnucash-1.1.23-4.i386.rpm: size md5 OK
� rpm -K --nopgp gnucash-1.1.23-4.i386.rpm
gnucash-1.1.23-4.i386.rpm: size md5 OK
Per i tipi veramente paranoici (e in questo caso ci sarebbe molto da
dire a proposito di paranoia), ci sono le utilit� unrpm e rpmunpack
disponibili presso la directory utils/package di Sunsite per estrarre
e controllare i singoli componenti dei pacchetti.
Klee Diene <mailto:
[email protected]> ha scritto il pacchetto
sperimentale dpkgcert, per la verifica dell'integrit� dei file .deb
installati, usando i codici di controllo MD5. � disponibile
nell'archivio ftp Debian
<
ftp://ftp.debian.org/pub/debian/project/experimental>. L'attuale nome
/ versione � dpkgcert_0.2-4.1_all.deb. Il sito Jim Pick Software
<
http://dpkgcert.jimpick.com> mantiene un server database sperimentale
per fornire certificati dpkgcert per i pacchetti di una tipica
installazione Debian.
Nella loro forma pi� semplice, i comandi rpm -i nomepacchetto.rpm e
dpkg --install nomepacchetto.deb automaticamente aprono il pacchetto
ed installano il software. Siate cauti, comunque, poich� usare tali
comandi ciecamente pu� essere pericoloso per la salute del vostro
sistema!
Notate che gli avvertimenti suddetti si applicano anche, sebbene in
minor misura, all'utilit� di installazione pkgtool della Slackware.
Tutto il software di installazione "automatico" richiede cautela.
I programmi martian
<
http://www.people.cornell.edu/pages/rc42/program/martian.html> e
alien <
http://kitenet.net/programs/alien/> permettono la conversione
tra i formati dei pacchetti rpm, deb, Stampede slp e tar.gz. Ci�
rende questi pacchetti accessibili a tutte le distribuzioni Linux.
Leggere attentamente le pagine di manuale dei comandi rpm e dpkg, e
fare riferimento all'RPM HOWTO, alla Quick Guide to Red Hat's Package
Manager <
http://www.tfug.org/helpdesk/linux/rpm.html> del TFUG, e a
The Debian Package Management Tools
<
http://www.debian.org/doc/FAQ/debian-faq-7.html> per informazioni pi�
dettagliate.
4.2. Problemi con gli rpm: un esempio
Jan Hubicka <mailto:
[email protected]> ha scritto un bellissimo
pacchetto per i frattali, chiamato xaos. Sulla sua home page
<
http://www.paru.cas.cz/~hubicka/XaoS> sono disponibili entrambi i
pacchetti .tar.gz e rpm. In nome della comodit� proviamo la versione
rpm, piuttosto che il pacchetto tar.
Sfortunatamente, l'rpm di xaos non si installa. Due diverse versioni
rpm fanno i capricci.
rpm -i --test XaoS-3.0-1.i386.rpm
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
rpm -i --test xaos-3.0-8.i386.rpm
error: failed dependencies:
libaa.so.1 is needed by xaos-3.0-8
La cosa strana � che libslang.so.0, libpng.so.0, e libaa.so.1 sono
tutte presenti nella directory /usr/lib del sistema usato. Gli rpm di
xaos 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 xaos-3.0-8.i386.rpm con l'opzione
--nodeps per forzarne l'installazione. Provando ad eseguire xaos si
pianta.
xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl
(errore nel caricamento delle librerie condivise, il simbolo __fabsl
non � definito)
Cerchiamo testardamente di andare in fondo alla cosa. Lanciando ldd
sul binario di xaos, per trovare da quali librerie dipende, vediamo
che le librerie necessarie ci sono tutte. Lanciando nm sulla libreria
/usr/lib/libaa.so.1, per vedere i suoi riferimenti simbolici, ci
accorgiamo che __fabsl manca davvero. Naturalmente il riferimento che
manca potrebbe non essere presente in una qualsiasi delle altre
librerie... Non c'� niente da fare, salvo rimpiazzare una o pi�
librerie.
Basta! Scarichiamo il pacchetto tar, XaoS-3.0.tar.gz, disponibile sul
sito ftp <
ftp://ftp.ta.jcu.cz/pub/linux/hubicka/XaoS/3.0> o reperibile
dalla home page. Proviamo a compilarlo. L'esecuzione di ./configure,
make e infine (come root) make install procede senza intoppi.
Questo � solo uno fra i tanti esempi di binari preimpacchettati che
portano pi� problemi che vantaggi.
5. Problemi riguardo termcap e terminfo
Secondo la pagina di manuale, "terminfo � un database che descrive i
terminali, usato da programmi orientati-allo-schermo...". 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� di
driver speciali. Le librerie terminfo si trovano in
/usr/share/terminfo, sulle moderne distribuzioni di Linux.
Il database terminfo ha ampiamente sostituito il pi� vecchio termcap
ed il completamente obsoleto termlib. Ci� normalmente non ha nessuna
attinenza con l'installazione dei programmi, eccetto quando si ha a
che fare con un pacchetto che richiede termcap.
La maggior parte delle distribuzioni Linux ora usano terminfo, ma
ancora conservano le librerie termcap per compatibilit� con le
applicazioni legacy (vedere /etc/termcap). A volte c'� uno speciale
pacchetto di compatibilit� che � necessario aver installato per
facilitare l'uso dei binari linkati con termcap. Raramente, potrebbe
essere necessario togliere il commento da una dichiarazione #define
termcap in un file sorgente. Controllate i file di documentazione
appropriati nella vostra distribuzione per informazioni a tal
riguardo.
6. Compatibilit� all'indietro con i binari a.out
In rarissimi casi, � necessario usare binari a.out, o perch� il codice
sorgente non � disponibile o perch�, per una qualche ragione, non �
possibile compilare nuovi binari ELF dal sorgente.
Come succede, le installazioni ELF hanno quasi sempre un completo
insieme di librerie a.out nella directory /usr/i486-linuxaout/lib. 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� essere in grado di
trovare le giuste librerie in fase di esecuzione, ma ci� 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�. Inoltre, alcune distribuzioni
di Linux richiedono l'installazione di uno speciale pacchetto di
compatibilit�, come xcompat di Debian, per eseguire applicazioni X
a.out.
6.1. Un esempio
Jerry Smith ha scritto il comodissimo programma xrolodex alcuni anni
fa. Esso usa le librerie Motif, ma fortunatamente � disponibile come
binario linkato staticamente in formato a.out. Sfortunatamente, il
sorgente necessita di numerosi aggiustamenti per essere ricompilato
usando le librerie lesstif. Ancor pi� sfortunatamente, il binario
a.out su di un sistema ELF va in bomba con il seguente messaggio
d'errore.
xrolodex: can't load library '//lib/libX11.so.3'
No such library
(Traducendo: non � possibile caricare la libreria //lib/libX11.so.3;
non c'� nessuna libreria con quel nome)
Si d� il caso che ci sia una tale libreria, in
/usr/i486-linuxaout/lib, ma xrolodex � incapace di trovarla in fase di
esecuzione. La soluzione semplice � di fornire un link simbolico nella
directory /lib:
ln -s /usr/i486-linuxaout/lib/X11.so.3.1.0 libX11.so.3
Ne viene fuori che � necessario fornire link simili per le librerie
libXt.so.3 e libc.so.4. Ci� 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�
alti delle pi� vecchie a.out, per prevenire ed impedire proprio tali
problemi.
Dopo aver creato i tre link, xrolodex funziona bene.
Il pacchetto xrolodex era originariamente pubblicato su Spectro
<
http://www.spectro.com/>, ma sembra che sia sparito da l�.
Attualmente pu� essere scaricato da Sunsite
<
http://metalab.unc.edu/pub/Linux/apps/reminder/xrolodex.tar.z> come
file sorgente [512k] in formato tar.Z.
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 <
http://www.lesstif.org/>). 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 <
http://redhat.com> e
Debian <
http://www.debian.org> 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.
8. Conclusioni
Leggete la documentazione del pacchetto software per stabilire se
certe variabili d'ambiente hanno bisogno di impostazioni (in .bashrc o
.cshrc) e se i file .Xdefaults e .Xresources hanno bisogno di essere
personalizzati.
Potrebbe esserci un file di default per l'applicazione, di solito
chiamato Xprog.ad nella distribuzione Xprog originale. Se � cos�,
editate il file Xprog.ad per adattarlo alla vostra macchina, poi
cambiategli nome (mv) in Xprog ed installatelo nella directory
/usr/lib/X11/app-defaults come root. Un insuccesso nel fare ci�
potrebbe far s� che il software si comporti stranamente o addirittura
si rifiuti di girare.
La maggior parte dei pacchetti software comprendono una o pi� pagine
di manuale preformattate. Come root, copiate il file Xprog.man nella
directory /usr/man, /usr/local/man, o /usr/X11R6/man appropriata (man1
- man9), 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 man1,
i giochi in man6, ed i pacchetti di amministrazione in man8 (vedere la
documentazione di man 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� essi non hanno l'opzione install nel
Makefile. In tal caso, potete installare manualmente i binari
copiandoli nell'appropriata directory di sistema, /usr/bin,
/usr/local/bin o /usr/X11R6/bin, come root, naturalmente. Notate che
/usr/local/bin � 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 make install, e
forse un make install.man o un make install_man. Se � cos�, i file di
documentazione README o INSTALL lo specificheranno.
9. Primo esempio: Xscrabble
L'Xscrabble di Matt Chapman aveva l'aria di essere un programma che
sarebbe stato interessante avere, poich� si d� il caso che io sia un
accanito giocatore di ScrabbleTM. Lo scaricai, decompressi, e lo
compilai seguendo la procedura nel file README:
xmkmf
make Makefiles
make includes
make
Ovviamente non funzion�...
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...
Indagai su ci� nel newsgroup comp.os.linux.x, e qualcuno gentilmente
mi indic� 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 src cattur�
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:
$(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LOCAL_LIBS) $(LDLIBS)
$(EXTRA_LOAD_FLAGS)
Ora, cos'erano queste LDLIBS?
LDLIBS = $(LDPOSTLIB) $(THREADS_LIBS) $(SYS_LIBRARIES)
$(EXTRA_LIBRARIES)
Le SYS_LIBRARIES erano:
SYS_LIBRARIES = -lXpm -L../Xc -lXc
S�! Le librerie mancanti erano qui.
� possibile che il linker avesse bisogno di vedere le LDLIBS prima
delle LOCAL_LIBS... Cos�, 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:
$(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LDLIBS) $(LOCAL_LIBS)
$(EXTRA_LOAD_FLAGS) ^^^^^^^^^^^^^^^^^^^^^^^
Provai ad eseguire di nuovo make con i suddetti cambiamenti e, guarda
un po', stavolta funzion�. 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 � disponibile una nuova versione di Xscrabble in
formato rpm, e questa si installa senza problemi.]
Potete contattare Matt Chapman <mailto:
[email protected]> via
e-mail, e scaricare Xscrabble dalla sua home page
<
http://www.belgarath.demon.co.uk/programs/index.html>.
Scrabble � un marchio registrato dalla Milton Bradley Co., Inc.
10. Secondo esempio: Xloadimage
Questo esempio pone un problema pi� facile. Il programma xloadimage
sembrava un'utile aggiunta alla mia raccolta di attrezzi grafici. Ho
copiato il file xloadi41.gz direttamente dalla directory sorgente sul
CD, allegato all'eccellente libro ``X User Tools'', di Mui e Quercia.
Come c'era da aspettarsi, tar xzvf estrae i file dall'archivio. Il
make, per�, fornisce un antipatico errore e termina.
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
Il messaggio d'errore contiene l'indizio essenziale.
Guardando il file image.h, linea 23...
#include <stdlib.h>
Aha, da qualche parte nel sorgente per xloadimage, wchar_t � stato
ridefinito in modo diverso da quanto specificato nel file include
standard, stdlib.h. Proviamo prima a commentare la linea 23 in
image.h, che forse l'include stdlib.h, dopo tutto, non � necessario.
A questo punto, la fase di compilazione procede senza nessun errore
fatale. Il pacchetto xloadimage funziona correttamente ora.
11. Terzo esempio: Fortune
Questo esempio richiede qualche conoscenza di programmazione in C. La
maggioranza del software UNIX/Linux � 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 fortune mostra una frase umoristica, un "biscotto
della fortuna", ad ogni avvio di Linux. Sfortunatamente (il gioco di
parole � 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")
~/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
Guardando fortune.c, le linee pertinenti sono queste.
if (dirent->d_namlen == 0)
continue;
name = copy(dirent->d_name, dirent->d_namlen);
Ci serve di trovare la struttura dirent, ma essa non � dichiarata nel
file fortune.c, e nemmeno un grep dirent la mostra in nessuno dei file
sorgenti. Tuttavia, all'inizio di fortune.c, c'� la seguente linea.
#include <dirent.h>
Questo sembra essere un file include per la libreria di sistema,
perci�, il posto pi� logico dove cercare dirent.h � in /usr/include.
Effettivamente esiste un file dirent.h in /usr/include, ma quel file
non contiene la dichiarazione della struttura dirent. C'�, per�, un
riferimento ad un altro file dirent.h.
#include <linux/dirent.h>
Alla fine, andando in /usr/include/linux/dirent.h, troviamo la
dichiarazione della struttura che ci serve.
struct dirent {
long d_ino;
__kernel_off_t d_off;
unsigned short d_reclen;
char d_name[256]; /* We must not include
limits.h! */
};
Poco ma sicuro, la dichiarazione della struttura non contiene nessun
d_namelen, ma ci sono un paio di "candidati" come suo equivalente. Il
pi� probabile di essi � d_reclen, poich� questo membro della struttura
probabilmente rappresenta la lunghezza di qualcosa ed � uno short
integer. L'altra possibilit�, d_ino, 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�
sembrerebbe convalidare la nostra scelta.
Editiamo il file fortune.c e cambiamo i due riferimenti alle linee 551
e 553 da d_namelen a d_reclen. Proviamo di nuovo un make all.
Successo. La compilazione finisce senza errori. Ora possiamo prenderci
i nostri "brividi a buon mercato" da fortune.
12. Quarto esempio: Hearts
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 Jonathan Badger <mailto:
[email protected]>. Il
suo predecessore era un ancor pi� vecchio programma Pascal di Don
Backus della Oregon Software, poi aggiornato da Jeff Hemmerling.
Originariamente pensato come client per pi� giocatori, funziona bene
anche per un solo giocatore contro avversari gestiti dal computer. La
grafica � bella, bench� il gioco manchi di caratteristiche pi�
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�, questo pacchetto � particolarmente
difficile da compilare su di un sistema Linux. Richiede la soluzione
di una lunga e sconcertante serie di puzzle. � un esercizio di
pazienza e determinazione.
Prima di iniziare, accertatevi di avere le librerie motif o le lesstif
installate.
�
xmkmf
make
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
Questi sono i colpevoli nel file client.c:
#ifndef SYSV
(buf[2] != _tty.sg_erase) && (buf[2] != _tty.sg_kill)) {
#else
(buf[2] != CERASE) && (buf[2] != CKILL)) {
#endif
�
In client.c, aggiungiamo
#define SYSV
alla linea 39. Ci� bypasser� il riferimento a _tty.
make
client.c:41: sys/termio.h: No such file or directory
make: *** [client.o] Error 1
�
Il file include termio.h � nella directory /usr/include su di un
sistema Linux, invece che nella /usr/include/sys, come era sulle
vecchie macchine UNIX. Perci�, cambiamo la linea 41 di client.c da
#include <sys/termio.h>
a
#include <termio.h>
make
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
�
Le moderne distribuzioni Linux usano il database terminfo e/o termcap,
piuttosto che l'obsoleto termlib.
Editiamo il Makefile.
Linea 655:
CURSES_LIBRARIES = -lcurses -ltermlib
cambiamola in:
CURSES_LIBRARIES = -lcurses -ltermcap
make
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
�
La principale libreria lesstif � libXm, piuttosto che libXm_s. Quindi,
editiamo il Makefile.
Nella linea 653:
XMLIB = -lXm_s $(XTOOLLIB) $(XLIB) -lPW
cambia in:
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW
make
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
�
Raduniamo i soliti sospetti.
Non c'� nessuna libreria PW. Editiamo il Makefile.
Linea 653:
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPW
cambia in:
XMLIB = -lXm $(XTOOLLIB) $(XLIB) -lPEX5
(La libreria PEX5 � quella pi� simile alla PW.)
make
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
Il make finalmente funziona (hurra!)
�
Installazione:
Come root,
[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
�
Esecuzione di prova:
rehash
(Stiamo eseguendo la shell tcsh.)
xmhearts
localhost:~/% xmhearts
Can't invoke distributor!
�
Dal file README nel pacchetto hearts:
Put heartsd, hearts_dist, and hearts.instr in the HEARTSLIB
directory defined in local.h and make them world-accessible.
(Traducendo: Mettete Heartsd, hearts_dist, e hearts.instr nella direc�
tory HEARTSLIB definita in local.h e rendeteli accessibili a chiunque)
Dal file local.h:
/* where the distributor, dealer and instructions live */
#define HEARTSLIB "/usr/local/lib/hearts"
Questo � un classico caso: RTFM (leggete il fottuto manuale).
Come root,
cd /usr/local/lib
mkdir hearts
cd !$
Copiamo i file di distributor in questa directory.
cp /home/username/hearts/heartsd .
cp /home/username/hearts/hearts_dist .
cp /home/username/hearts/hearts.instr .
�
Lanciamo un'altra esecuzione di prova.
xmhearts
Qualche volta funziona, ma il pi� delle volte si pianta con un
messaggio dealer died!.
�
Il "distributor" e il "dealer" esaminano le porte hardware. Dovremmo
perci� sospettare che quei programmi abbiano bisogno dei privilegi di
root.
Proviamo, come root,
chmod u+s /usr/local/lib/heartsd
chmod u+s /usr/local/lib/hearts_dist
(Osserviamo che, come discusso precedentemente, i binari suid possono
creare dei buchi di sicurezza.)
xmhearts
Alla fine funziona!
Hearts � disponibile da Sunsite.
13. Quinto esempio: XmDipmon
Bullwinkle: Hey Rocky, guarda, tiro fuori un coniglio dal cappello.
Rocky: Ma quel trucco non funziona mai.
Bullwinkle: Questa volta s�.
Voil�!
Beh, ci sono andato vicino.
Rocky: Ed ora � il momento di un altro effetto speciale.
--- "Rocky e i suoi amici"
XmDipmon � 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
dip, il che lo rende inutile per tutti quelli, la maggioranza, che
usano chat per collegarsi.
Compilare XmDipmon non � un problema. XmDipmon si linka con le
librerie Motif, ma pu� essere compilato, e funziona bene, anche con le
Lesstif. La sfida � di modificare il pacchetto per farlo funzionare
con chat. Ci� in pratica richiede di armeggiare con il codice sorgente
ed � quindi necessario avere delle conoscenze di programmazione.
"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
Usando l'opzione -pidfile, il programma pu� essere indotto, al suo
avvio, a cercare un altro file, uno che esista solo dopo che un login
con chat � stato effettuato con successo. Il candidato pi� ovvio � il
file di lock del modem. Potremmo quindi provare a lanciare il
programma con xmdipmon -pidfile /var/lock/LCK..ttyS3 (assumendo che il
modem sia sulla porta com numero 4, ttyS3). Comunque cos� si risolve
solo una parte del problema. Il programma osserva continuamente il
demone dip e dobbiamo invece fare in modo che controlli un processo
che sia associato a chat o a ppp.
C'� un solo file sorgente e fortunatamente � ben commentato.
Scorrendo il file xmdipmon.c troviamo la funzione getProcFile, la cui
descrizione, all'inizio, riporta quanto segue:
/*****
* Name: getProcFile
* Return Type: Boolean
* Description: tries to open the /proc entry as read from the dip pid file.
<snip>
*****/
(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...
/* 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';
Il colpevole � la linea 2383:
sprintf(buf, "/proc/%i/status", pid);
^^^^^^^^^^^^^^^^^^^^^
Questo controlla se il processo demone dip � in esecuzione. Quindi,
come possiamo cambiarlo in modo che controlli il demone pppd?
Guardando sulla pagina di manuale di pppd:
FILES
/var/run/pppn.pid (BSD o Linux), /etc/ppp/pppn.pid (altri)
Identificatore del processo (Process-ID) di pppd sull'unit�
d'interfaccia n di ppp.
Cambiamo la linea 2383 di xmdipmon.c in:
sprintf(buf, "/var/run/ppp0.pid" );
Ricompiliamo il pacchetto cos� modificato. Nessun problema con la
compilazione. Ora proviamolo con il nuovo argomento della riga di
comando. Funziona che � un incanto. Il bottoncino blu indica quando �
stata stabilita una connessione ppp con l'ISP e lampeggia e suona
quando la connessione si interrompe. Ora abbiamo un monitor per chat
pienamente funzionante.
XmDipmon pu� essere scaricato da Ripley Linux Tools.
14. Dove trovare archivi sorgente
Ora che siete ansiosi di usare le conoscenze appena acquisite, per
aggiungere delle utilit� ed altre chicche al vostro sistema, potete
trovarle online alla Linux Applications and Utilities Page
<
http://www.redhat.com/linux-info/linux-app-list/linapps.html>, o in
una delle raccolte su CD ROM, a prezzo molto ragionevole, di Red Hat
<
http://www.redhat.com/>, InfoMagic <
http://www.infomagic.com>, Linux
Systems Labs <
http://www.lsl.com>, Cheap Bytes
<
http://www.cheapbytes.com>, e altri.
Un vasto magazzino di codice sorgente � comp sources UNIX archive.
Molto codice sorgente UNIX viene pubblicato nel newsgroup alt.sources.
Se state cercando particolari pacchetti di codice sorgente, potete
chiedere sullo specifico newsgroup alt.sources.wanted. Un altro buon
posto dove cercare � il newsgroup comp.os.linux.announce. Per entrare
nella mailing list Unix sources, mandate alla stessa un messaggio
subscribe.
Gli archivi del newsgroup alt.sources si trovano presso i seguenti
siti ftp:
� ftp.sterling.com/usenet/alt.sources/
� wuarchive.wustl.edu/usenet/alt.sources/articles
� src.doc.ic.ac.uk/usenet/alt.sources/articles
15. Conclusioni
Riassumendo, la perseveranza fa tutta la differenza (e un'alta soglia
alla frustrazione certamente aiuta). Come in tutti gli sforzi,
imparare dagli errori � criticamente importante. Ogni passo falso,
ogni fallimento, contribuisce alla costruzione della conoscenza che
conduce alla padronanza dell'arte della compilazione del software.
16. Riferimenti e ulteriori letture
BORLAND C++ TOOLS AND UTILITIES GUIDE, Borland International, 1992,
pp. 9-42.
[Uno dei manuali distribuiti col Borland C++, ver. 3.1. D� 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.
[� 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� 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� 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� 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.
[Questi HOWTO dovrebbero trovarsi nella directory /usr/doc/HOWTO o
nella /usr/doc/HOWTO/mini sul vostro sistema. Versioni aggiornate sono
disponibili in formato testo, HTML e SGML nel sito LDP
<
http://metalab.unc.edu/LDP/HOWTO>, e di solito nei siti dei
rispettivi autori.]
__________________
Traduzioni: Per la versione in italiano degli HOWTO con l'indicazione
"(tradotto)" vedere: www.pluto.linux.it/ildp/HOWTO/HOWTO-INDEX-3.html.
Per altra documentazione su Linux in italiano, compresi eventuali
HOWTO e/o mini-HOWTO citati ma al momento non ancora tradotti, si veda
il sito ILDP <
http://www.pluto.linux.it/ildp/index.html>.
17. Crediti
L'autore di questo HOWTO desidera ringraziare le seguenti persone per
gli utili suggerimenti, le correzioni e l'incoraggiamento.
� R. Brock Lynn
� Michael Jenner
� Fabrizio Stefani
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 Linux Documentation Project
<
http://metalab.unc.edu/LDP/>.
