[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
La maggior parte dei programmi per Unix il cui utilizzo viene concesso gratuitamente, viene distribuita in forma sorgente. Ciò significa che per poterli utilizzare, questi programmi devono essere compilati. Fortunatamente, nella maggior parte dei sistemi Unix è disponibile il compilatore ANSI C GNU che permette di uniformare questo procedimento di compilazione.
Alcuni programmi vengono distribuiti in forma già compilata (e senza sorgenti) soprattutto quando si tratta di prodotti proprietari. Anche in questi casi si possono incontrare problemi nell'installazione.
In generale, i problemi che derivano dall'installazione di questi applicativi nasce dalla mancanza di sostegno da parte del sistema di gestione dei pacchetti della propria distribuzione GNU/Linux.
Un programma distribuito in forma sorgente si trova di solito confezionato in un archivio il cui nome ha un'estensione .tar.gz o .tgz (ottenuto attraverso tar e gzip), oppure ancora con un'estensione .tar.bz2 (tar e bzip2). Prima di poter procedere con la sua compilazione deve essere estratto il suo contenuto. Solitamente si fa questo in una directory di lavoro. Nell'esempio che segue, si fa riferimento a un pacchetto ipotetico archiviato nel file pacch.tar.gz:
$ cd ~/tmp
$ tar xzvf pacch.tar.gz
Se invece si trattasse dell'archivio pacch.tar.bz2, sarebbe stato necessario decomprimerlo attraverso un comando un po' più complesso:
$ cd ~/tmp
$ cat pacch.tar.bz2 | bunzip2 | tar xvf -
Di solito si ottiene una struttura ad albero più o meno articolata in sottodirectory, dove nella directory principale di questa struttura si trovano:
uno o più file di documentazione (README, INSTALL, ecc.) che servono per ricordare il procedimento corretto per ottenere la compilazione;
uno o più script preparati per facilitare questo procedimento;
Seguendo l'esempio visto poco prima, dovrebbe essere stata creata la directory pacch/.
$ cd pacch
$ ls
I file di testo che si trovano nella directory principale del pacchetto contenente il programma sorgente, servono per presentare brevemente il programma e per riassumere le istruzioni necessarie alla sua compilazione. Di solito, queste ultime sono contenute nel file INSTALL. In ogni caso, tutti questi file vanno letti, in particolare quello che spiega il procedimento per la compilazione e l'installazione.
Il modo più semplice per leggere un file è l'utilizzo del programma less, o in sua mancanza di more.
$ less README
$ less INSTALL
La composizione classica di un pacchetto distribuito in forma sorgente, prevede la presenza di uno script il cui scopo è quello di costruire un file-make adatto all'ambiente in cui si vuole compilare il programma. Ciò è necessario perché i vari sistemi Unix sono diversi tra loro per tanti piccoli dettagli.
Spesso questo script è in grado di accettare argomenti. Ciò può permettere, per esempio, di definire una directory di destinazione del programma, diversa da quella predefinita.
Quando questo script di preparazione manca, occorre modificare manualmente il file-make in modo che sia predisposto correttamente per la compilazione nel proprio sistema.
|
Per evitare ambiguità, questo script viene sempre avviato indicando un percorso preciso: |
Il file-make, o makefile, è quel file che viene letto da Make, precisamente dall'eseguibile make, allo scopo di coordinare le varie fasi della compilazione ed eventualmente anche per l'installazione del programma compilato. Il nome di questo file può essere diverso, generalmente si tratta di Makefile, oppure di makefile.
Questo file viene generato frequentemente da uno script, di solito si tratta di ./configure, ma se manca deve essere controllato e, se necessario, modificato prima della compilazione.
|
Spesso è bene controllare il contenuto del file-make anche quando questo è stato generato automaticamente. |
I pacchetti più comuni si compilano e si installano con tre semplici operazioni.
$ ./configure
Genera automaticamente il file-make.
$ make
Esegue la compilazione generando i file eseguibili.
# make install
Installa gli eseguibili e gli altri file necessari nella loro destinazione prevista per il funzionamento: l'ultima fase deve essere eseguita con i privilegi dell'utente root.
Le note di questo capitolo valgono solo in linea di massima: è sempre indispensabile leggere le istruzioni che si trovano nei file di testo distribuiti insieme ai sorgenti dei programmi.
I problemi maggiori si hanno quando non è stato predisposto uno script ./configure o simile e si è costretti a modificare il file-make.
In altri casi, il file-make potrebbe non prevedere la fase di installazione (make install), per cui si deve installare il programma copiando pezzo per pezzo nella destinazione giusta.
Spesso l'installazione non rispetta la struttura standard del proprio file system. Ciò nel senso che magari vengono piazzati file che devono poter essere modificati, all'interno di una zona che si voleva riservare in sola lettura.
Quando si utilizza una distribuzione GNU/Linux ben organizzata, si trova una gestione dei pacchetti installati che permette l'eliminazione e l'aggiornamento di questi senza rischiare di lasciare file inutilizzati in giro. Quando si installa un programma distribuito in forma originale, viene a mancare questo supporto della gestione dei pacchetti. In questi casi si cerca di installare tali pacchetti al di sotto della directory /opt/, o almeno al di sotto di /usr/local/.
L'installazione di programmi già compilati per GNU/Linux, anche se potrebbe sembrare più semplice rispetto a un procedimento che richiede la compilazione, potrebbe creare qualche problema a chi non conosce perfettamente l'interdipendenza che c'è tra le varie parti del sistema operativo.
I problemi e le soluzioni che si descrivono nelle sezioni seguenti, riguardano a volte anche i programmi distribuiti in forma sorgente. Infatti, alcune volte, i programmi distribuiti in questo modo non sono stati preparati per un'installazione soddisfacente, di conseguenza bisogna provvedere da soli a collocare i file nelle posizioni corrette e a sistemare tutto quello che serve.
Quando si cerca del software per il proprio sistema che può essere ottenuto solo in forma già compilata, occorre fare attenzione alla piattaforma. Infatti, non basta che si tratti di programmi compilati per GNU/Linux, occorre che gli eseguibili siano adatti al tipo di elaboratore su cui GNU/Linux è in funzione.
Normalmente, per identificare l'architettura dei «PC», si utilizza la sigla i386 nel nome dei file degli archivi.
Un programma distribuito in forma binaria, deve essere estratto normalmente dall'archivio compresso che lo contiene. A volte è disponibile uno script o un programma di installazione, altre volte è necessario copiare manualmente i file nelle varie destinazioni finali. Quando si può scegliere, è preferibile collocare tutto quanto a partire da un'unica directory discendente da /opt/.
A volte, perché il programma possa funzionare è necessario predisporre o modificare il contenuto di alcune variabili di ambiente. Il caso più comune è costituito da PATH che deve (o dovrebbe) contenere anche il percorso necessario ad avviare il nuovo programma. Spesso, i file di documentazione che accompagnano il software indicano chiaramente tutte le variabili che devono essere presenti durante il loro funzionamento.
La dichiarazione di queste variabili può essere collocata direttamente in uno dei file di configurazione della shell utilizzata (per esempio /etc/profile, oppure ~/.bash_profile o altri ancora a seconda di come è organizzato il proprio sistema).
Alcuni programmi utilizzano delle librerie non standard, che spesso vengono collocate al di fuori delle directory predisposte per contenerle. Per fare in modo che queste librerie risultino disponibili, ci sono due modi possibili:
modificare la configurazione di /etc/ld.so.cache;
utilizzare la variabile di ambiente LD_LIBRARY_PATH.
Per agire secondo la prima possibilità, occorre prima comprendere come sia organizzato questo sistema. Il file /etc/ld.so.cache viene creato a partire da /etc/ld.so.conf che contiene semplicemente un elenco di directory destinate a contenere librerie. Il programma ldconfig serve proprio a ricreare il file /etc/ld.so.cache leggendo /etc/ld.so.conf, pertanto viene avviato solitamente dalla stessa procedura di inizializzazione del sistema, allo scopo di garantire che questo file sia sempre aggiornato.
Dovrebbe essere chiaro, ormai, il modo giusto di includere nuovi percorsi di librerie nel file /etc/ld.so.cache: occorre indicare questa o queste directory nel file /etc/ld.so.conf e quindi basta avviare il programma ldconfig.
L'utilizzo della variabile di ambiente LD_LIBRARY_PATH è meno impegnativo, ma soprattutto, in questo modo si può intervenire facilmente attraverso dei semplici script. Ciò permette, per esempio, di fare in modo che solo un certo programma «veda» certe librerie. In ogni caso, quando si intende usare questa variabile di ambiente, è importante ricordare di includere tra i vari percorsi anche quelli standard: /lib/, /usr/lib/ e /usr/local/lib/. L'esempio seguente rappresenta un pezzo di uno script (potrebbe trattarsi di /etc/profile) in cui viene assegnata la variabile di ambiente in questione.
LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/opt/mio_prog/lib:/opt/tuo_prog/lib export LD_LIBRARY_PATH
Se un certo programma richiede determinate librerie che potrebbero entrare in conflitto con altri programmi, è indispensabile l'utilizzo della variabile di ambiente LD_LIBRARY_PATH, configurandola esclusivamente nell'ambito del processo di quel programma. In pratica, si tratta di avviare il programma attraverso uno script che genera l'ambiente adatto, in modo che non si rifletta negli altri processi, come mostrato nell'esempio seguente:
#! /bin/sh # modifica il percorso di ricerca delle librerie LD_LIBRARY_PATH="/opt/mio_programma/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH # avvia il programma mio_programma # al termine dello script non resta traccia
Avviando lo script, viene modificata la variabile di ambiente LD_LIBRARY_PATH per quel processo e per i suoi discendenti (viene esportata), quindi, al termine del programma termina lo script e con lui anche gli effetti di queste modifiche.
Si osservi in particolare il fatto che nella nuova definizione del percorso delle librerie, viene posto all'inizio quello per le librerie specifiche del programma, in modo che venga utilizzato per primo; subito dopo, viene inserito l'elenco dei percorsi eventualmente già esistente.
ldd [opzioni] programma...
ldd emette l'elenco delle librerie condivise richieste dai programmi indicati come argomenti della riga di comando. Si utilizza ldd per determinare le dipendenze di uno o più programmi dalle librerie.
$ ldd /bin/bash[Invio]
libncurses.so.4 => /usr/lib/libncurses.so.4 (0x40000000)
libdl.so.1 => /lib/libdl.so.1.7.14 (0x40045000)
libc.so.5 => /lib/libc.so.5.4.38 (0x40048000)
L'esempio mostra le dipendenze dalle librerie di /bin/bash. Il risultato ottenuto indica il nome delle librerie e la collocazione effettiva nel sistema, risolvendo anche eventuali collegamenti simbolici.
Quando si ha a che fare con programmi il cui aggiornamento è frequente, come avviene nel caso del kernel, si possono anche trovare aggiornamenti in forma di file di differenze (patch), cioè di file che contengono solo le variazioni da una versione all'altra. Queste variazioni si applicano ai file di una versione per ottenerne un'altra.
Se la versione da aggiornare è stata espansa a partire dall'ipotetica directory ~/tmp/, per applicarvi una modifica, sarà necessario posizionarsi sulla stessa directory e poi eseguire il comando seguente:
patch < file_di_differenze
Può darsi che la posizione in cui ci si deve trovare sia diversa o che i sorgenti da aggiornare debbano trovarsi in una posizione precisa. Per capirlo, dovrebbe bastare l'osservazione diretta del contenuto del file di differenze.
L'applicazione delle variazioni, può fallire. Se non si vuole perdere il rapporto degli errori, questi possono essere ridiretti in un file specifico.
patch < file_di_differenze 2> file_degli_errori
Se gli aggiornamenti sono più d'uno, occorre applicare le modifiche in sequenza.
Il capitolo 82 tratta meglio questo problema.
Oltre al problema delle librerie specifiche di un programma particolare, cosa già descritta in questo capitolo, ci può essere la necessità di aggiornare le librerie standard di GNU/Linux a seguito di qualche aggiornamento di altro software.
Normalmente, la propria distribuzione GNU/Linux dovrebbe offrire questi aggiornamenti in forma di archivi già pronti, installabili attraverso il proprio sistema di gestione dei pacchetti. Ciò garantendo la sistemazione di una serie di dettagli importanti.
Quando si è costretti a fare da soli è importante fare attenzione. In particolare, quando si interviene in ciò che risiede nella directory /lib/, se si commette un errore, si rischia di bloccare il sistema senza possibilità di rimedio.
I file delle librerie sono organizzati normalmente con un numero di versione piuttosto articolato. Quando ciò accade, è normale che a questi file siano affiancati una serie di collegamenti simbolici strutturati in modo che si possa accedere a quelle librerie anche attraverso l'indicazione di versioni meno dettagliate, oppure semplicemente attraverso nomi differenti. Questi collegamenti sono molto importanti perché ci sono dei programmi che dipendono da questi; quando si aggiorna una libreria occorre affiancare la nuova versione a quella vecchia, quindi si devono modificare questi collegamenti. Solo alla fine, sperando che tutto sia andato bene, si può eliminare eventualmente il vecchio file di libreria.
Per fare un esempio pratico, si suppone di disporre della libreria libc.so.9.8.7, articolata nel modo seguente:
libc.so -> libc.so.9 libc.so.9 -> libc.so.9.8.7 libc.so.9.8.7
Volendo sostituire questa libreria con la versione 9.8.10, il cui file ha il nome libc.so.9.8.10, occorre procedere come segue:
# ln -s -f libc.so.9.8.10 libc.so.9
Come si vede, per generare il collegamento, è stato necessario utilizzare l'opzione -f che permette di sovrascrivere il collegamento preesistente. Infatti, non sarebbe stato possibile eliminare prima il collegamento vecchio, perché così si sarebbe rischiato il blocco del sistema.
libc.so -> libc.so.9 libc.so.9 -> libc.so.9.8.10 libc.so.9.8.7 libc.so.9.8.10
In generale, per sicurezza, è meglio lasciare le librerie vecchie, perché ci potrebbero essere ugualmente dei programmi che ne hanno ancora bisogno.
Quando la libreria da aggiornare ha subito un aggiornamento molto importante, per cui i numeri delle versioni sono molto distanti rispetto a quanto si utilizzava prima, conviene evitare di sostituirle, mentre è solo il caso di affiancarle. Volendo ritornate all'esempio precedente, si può supporre che la libreria da aggiornare sia arrivata alla versione 10.1.1, con il file libc.so.10.1.1. Intuitivamente si comprende che il collegamento simbolico libc.so.9 non può puntare a questa nuova libreria, mentre resta il dubbio per libc.so.
In generale è meglio lasciare stare le cose come sono, a meno di scoprire che qualche programma cerca proprio la libreria libc.so e si lamenta perché non si tratta della versione adatta a lui. Comunque, sempre seguendo l'esempio, sarebbe il caso di riprodurre un collegamento equivalente a libc.so.9, denominato ovviamente libc.so.10.
libc.so -> libc.so.9 libc.so.9 -> libc.so.9.8.7 libc.so.9.8.7 libc.so.10 -> libc.so.10.1.1 libc.so.10.1.1
daniele @ swlibero.orgDovrebbe essere possibile fare riferimento a questa pagina anche con il nome applicativi_distribuiti_in_forma_sorgente_o_compilata.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]