  Building and Installing Software Packages for Linux
  _M_e_n_d_e_l _C_o_o_p_e_r _<mailto:thegrendel@theriver.com> ---
  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.
  ______________________________________________________________________

  Indice Generale


  1. Introduzione
  2. Spacchettare i file
  3. Usare make
  4. Binari preimpacchettati
     4.1 Cosa c' che non va negli rpm?
     4.2 Problemi con gli rpm: un esempio

  5. Problemi riguardo termcap e terminfo
  6. Compatibilit all'indietro con i binari a.out
     6.1 Un esempio

  7. Risoluzione dei problemi
     7.1 Errori in fase di link
     7.2 Altri problemi
     7.3 Ritocchi e messa a punto
     7.4 Dove trovare maggiore aiuto

  8. Conclusioni
  9. Primo esempio: Xscrabble
  10. Secondo esempio: Xloadimage
  11. Terzo esempio: Fortune
  12. Quarto esempio: Hearts
  13. Quinto esempio: XmDipmon
  14. Dove trovare archivi sorgente
  15. Conclusioni
  16. Riferimenti e ulteriori letture
  17. Crediti


  ______________________________________________________________________

  11..  IInnttrroodduuzziioonnee

  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2..  SSppaacccchheettttaarree ii ffiillee

  Avete scaricato o vi siete procurati in altro modo un pacchetto
  software.  Molto probabilmente  archiviato (in formato _t_a_r) e
  compresso (in formato _g_z_i_p), 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 _g_u_n_z_i_p) e spacchettatelo (con _t_a_r). Il
  comando appropriato per farlo  ttaarr xxzzvvff _n_o_m_e_f_i_l_e, dove _n_o_m_e_f_i_l_e  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 uunnccoommpprreessss,
  seguito da ttaarr xxvvff. Potete vedere un'anteprima di tale processo con
  ttaarr ttzzvvff nnoommeeffiillee, 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 _t_a_r a prendere il suo input dallo stdin.)

  I file sorgenti nel nuovo formato _b_z_i_p_2 (.bz2) possono essere estratti
  con un bbzziipp22 --ccdd nnoommeeffiillee || ttaarr xxvvff --, o, pi semplicemente, con un
  ttaarr xxyyvvff nnoommeeffiillee, 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_, _-_-_b_z_i_p_2_, _-_-_b_u_n_z_i_p_2.

  [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 nnoonn si dovrebbe modificare il file Imake, poich ci potrebbe
  avere conseguenze impreviste. La maggior parte dei pacchetti
  permettono di automatizzare questo processo eseguendo mmaakkee iinnssttaallll per
  mettere i binari nelle appropriate aree di sistema.


    Potreste incontrare file shar, o _a_r_c_h_i_v_i _s_h_e_l_l, 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 uunnsshhaarr
     nnoommeeffiillee..sshhaarr.  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 _z_i_p, _a_r_c,
     _l_h_a, _a_r_j, _z_o_o, _r_a_r,e _s_h_k. 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 _p_a_t_c_h di Larry
  Wall  ppaattcchh << ppaattcchhffiillee.

  Ora potete procedere alla fase di compilazione del processo.



  33..  UUssaarree mmaakkee

  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 _m_a_k_e di solito richiede solo di battere mmaakkee. 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 (mmaakkee
  iinnssttaallll) e rimuovere i file oggetto stantii (mmaakkee cclleeaann). L'esecuzione
  di mmaakkee --n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. _I_m_a_k_e e _x_m_k_m_f 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 xxmmkkmmff, 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 xxmmkkmmff). 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 mmaakkee iinnssttaallll 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 _w_r_i_t_e _a_c_c_e_s_s _d_e_n_i_e_d (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, xxmmkkmmff usa il file Imake per costruire il
  Makefile appropriato per il vostro sistema. Sarete soliti invocare
  xxmmkkmmff con l'argomento --aa, per effettuare automaticamente _m_a_k_e
  _M_a_k_e_f_i_l_e_s, _m_a_k_e _i_n_c_l_u_d_e_s e _m_a_k_e _d_e_p_e_n_d. 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 ..//ccoonnffiigguurree 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, mmaakkee iinnssttaallll.
  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 xxmmkkmmff --aa, o lo script INSTALL o configure.

    Controllare il Makefile.

    Se necessario, eseguire mmaakkee cclleeaann, mmaakkee MMaakkeeffiilleess, mmaakkee iinncclluuddeess,
     e mmaakkee ddeeppeenndd.

    Eseguire mmaakkee.

    Controllare i permessi.

    Se necessario, eseguire mmaakkee iinnssttaallll.


  _N_o_t_e_:


    Normalmente non si compilano i pacchetti come root. L'effettuare un
     ssuu a root  necessario solo per installare i binari compilati nelle
     directory di sistema.

    Una volta che avete preso confidenza con _m_a_k_e 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 _-_O_2, _-_f_o_m_i_t_-_f_r_a_m_e_-_p_o_i_n_t_e_r, _-_f_u_n_r_o_l_l_-_l_o_o_p_s e _-_m_p_e_n_t_i_u_m (se
     usate un processore Pentium). Siate cauti e fatevi guidare dal buon
     senso quando modificate un Makefile!

    Dopo che _m_a_k_e ha creato i binari, potreste voler usare ssttrriipp su
     essi. Il comando ssttrriipp 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 _d_i_r_e_c_t_o_r_y _d_i
     _r_a_c_c_o_l_t_a separate. Questi archivi sono degli ordinari _p_a_c_c_h_e_t_t_i
     _t_a_r, ma si installano nelle directory /coll e /pack.  Potreste
     dover scaricare il _P_a_c_k_-_C_o_l_l_e_c_t_i_o_n dal suddetto sito qualora vi
     capiti di imbattervi in una di tali distribuzioni.



  44..  BBiinnaarrii pprreeiimmppaacccchheettttaattii



  44..11..  CCoossaa cc'' cchhee nnoonn vvaa nneeggllii rrppmm??


  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 _r_p_m e _d_e_b, o il
  pi recente Stampede _s_l_p. Sebbene possa essere vero che
  l'installazione di un _r_p_m 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 _r_p_m
  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 _r_p_m o un _d_e_b. Alcuni pacchetti meno
  popolari potrebbero non essere mai convertiti in _r_p_m.

  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 _r_p_m 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 rrppmm ----rreeccoommppiillee nnoommeeppaacccchheettttoo..rrppmm oppure
  rrppmm ----rreebbuuiilldd nnoommeeppaacccchheettttoo..rrppmm.

  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 _r_p_m o un _d_e_b 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 _r_p_m.


  L'installazione di un pacchetto _r_p_m non  necessariamente una
  bazzecola. Se c' un conflitto di dipendenza, l'installazione dell'_r_p_m
  fallir. L'_r_p_m 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 _r_p_m spesso falliscono per le stesse ragioni per cui lo fanno
  quelle dei pacchetti tar.

  Dovete installare gli _r_p_m e i _d_e_b 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 _c_a_v_a_l_l_o _d_i _T_r_o_i_a che potrebbe
  liberare il caos sul vostro sistema.  quindi importante ottenere
  pacchetti _r_p_m e _d_e_b da una "fonte fidata". In ogni caso, dovreste
  eseguire una 'verifica della firma' (rispetto ad un codice di
  controllo MD5) sul pacchetto, rrppmm ----cchheecckkssiigg nnoommeeppaacccchheettttoo..rrppmm, prima
  di installarlo. Allo stesso modo  fortemente raccomandata
  l'esecuzione di rrppmm --KK ----nnooppggpp nnoommeeppaacccchheettttoo..rrppmm. I comandi
  corrispondenti per i pacchetti _d_e_b sono ddppkkgg --II || ----iinnffoo
  nnoommeeppaacccchheettttoo..ddeebb e ddppkkgg --ee || ----ccoonnttrrooll nnoommeeppaacccchheettttoo..ddeebb.


    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 _u_n_r_p_m e _r_p_m_u_n_p_a_c_k
  disponibili presso la directory utils/package di Sunsite per estrarre
  e controllare i singoli componenti dei pacchetti.

  Klee Diene <mailto:klee@debian.org> ha scritto il pacchetto
  sperimentale _d_p_k_g_c_e_r_t, per la verifica dell'integrit dei file _._d_e_b
  installati, usando i codici di controllo MD5.   disponibile
  nell'archivio ftp Debian
  <ftp://ftp.debian.org/pub/debian/project/experimental>. L'attuale nome
  / versione  _d_p_k_g_c_e_r_t___0_._2_-_4_._1___a_l_l_._d_e_b. Il sito Jim Pick Software
  <http://dpkgcert.jimpick.com> mantiene un server database sperimentale
  per fornire certificati _d_p_k_g_c_e_r_t per i pacchetti di una tipica
  installazione Debian.

  Nella loro forma pi semplice, i comandi rrppmm --ii nnoommeeppaacccchheettttoo..rrppmm e
  ddppkkgg ----iinnssttaallll nnoommeeppaacccchheettttoo..ddeebb 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 _p_k_g_t_o_o_l 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 _r_p_m, _d_e_b, Stampede _s_l_p e _t_a_r_._g_z.  Ci
  rende questi pacchetti accessibili a tutte le distribuzioni Linux.

  Leggere attentamente le pagine di manuale dei comandi _r_p_m e _d_p_k_g, 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4..22..  PPrroobblleemmii ccoonn ggllii rrppmm:: uunn eesseemmppiioo


  Jan Hubicka <mailto:hubicka@paru.cas.cz> ha scritto un bellissimo
  pacchetto per i frattali, chiamato _x_a_o_s. 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 _x_a_o_s non si installa. Due diverse versioni
  rpm fanno i capricci.

  rrppmm --ii ----tteesstt XXaaooSS--33..00--11..ii338866..rrppmm


       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



  rrppmm --ii ----tteesstt xxaaooss--33..00--88..ii338866..rrppmm


       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
  _x_a_o_s 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
  _-_-_n_o_d_e_p_s per forzarne l'installazione. Provando ad eseguire _x_a_o_s 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 _l_d_d
  sul binario di _x_a_o_s, per trovare da quali librerie dipende, vediamo
  che le librerie necessarie ci sono tutte. Lanciando _n_m sulla libreria
  /usr/lib/libaa.so.1, per vedere i suoi riferimenti simbolici, ci
  accorgiamo che _____f_a_b_s_l manca davvero. Naturalmente il riferimento che
  manca _p_o_t_r_e_b_b_e 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 ..//ccoonnffiigguurree,
  mmaakkee e infine (come root) mmaakkee iinnssttaallll procede senza intoppi.

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



  55..  PPrroobblleemmii rriigguuaarrddoo tteerrmmccaapp ee tteerrmmiinnffoo



  Secondo la pagina di manuale, _"_t_e_r_m_i_n_f_o _ _u_n _d_a_t_a_b_a_s_e _c_h_e _d_e_s_c_r_i_v_e _i
  _t_e_r_m_i_n_a_l_i_, _u_s_a_t_o _d_a _p_r_o_g_r_a_m_m_i _o_r_i_e_n_t_a_t_i_-_a_l_l_o_-_s_c_h_e_r_m_o_._._._".  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 _t_e_r_m_i_n_f_o si trovano in
  /usr/share/terminfo, sulle moderne distribuzioni di Linux.

  Il database _t_e_r_m_i_n_f_o ha ampiamente sostituito il pi vecchio _t_e_r_m_c_a_p
  ed il completamente obsoleto _t_e_r_m_l_i_b.  Ci normalmente non ha nessuna
  attinenza con l'installazione dei programmi, eccetto quando si ha a
  che fare con un pacchetto che richiede _t_e_r_m_c_a_p.

  La maggior parte delle distribuzioni Linux ora usano _t_e_r_m_i_n_f_o, ma
  ancora conservano le librerie _t_e_r_m_c_a_p 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 _#_d_e_f_i_n_e
  _t_e_r_m_c_a_p in un file sorgente. Controllate i file di documentazione
  appropriati nella vostra distribuzione per informazioni a tal
  riguardo.



  66..  CCoommppaattiibbiilliitt aallll''iinnddiieettrroo ccoonn ii bbiinnaarrii aa..oouutt


  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6..11..  UUnn eesseemmppiioo


  Jerry Smith ha scritto il comodissimo programma _x_r_o_l_o_d_e_x 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 _l_e_s_s_t_i_f. 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, _x_r_o_l_o_d_e_x funziona bene.

  Il pacchetto _x_r_o_l_o_d_e_x 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 _t_a_r_._Z.



  77..  RRiissoolluuzziioonnee ddeeii pprroobblleemmii


  Se _x_m_k_m_f e/o _m_a_k_e 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7..11..  EErrrroorrii iinn ffaassee ddii lliinnkk


    Supponiamo che _m_a_k_e 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 _I_m_a_k_e non  stato preparato correttamente.  Controllate che
     nella prima parte del _M_a_k_e_f_i_l_e 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 _l_i_b_r_a_r_y e _i_n_c_l_u_d_e, rispettivamente.  In questo esempio, le
  _l_i_b_r_e_r_i_e _d_i _X_1_1 dovrebbero essere nella directory /usr/X11/lib, e i
  _f_i_l_e _i_n_c_l_u_d_e _d_i _X_1_1 dovrebbero essere nella directory
  /usr/X11/include/X11. Se sulla vostra macchina non  cos, apportate i
  cambiamenti necessari al _M_a_k_e_f_i_l_e e riprovate il _m_a_k_e.


    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 --llmm al flag _L_I_B o _L_I_B_S nel Makefile (vedere esempio
  precedente).



    Ancora un'altra cosa da provare se _x_m_k_m_f fallisce  lo script
     seguente:


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



  Che  una specie di _x_m_k_m_f ridotto all'osso.


    In rarissimi casi, l'esecuzione di _l_d_c_o_n_f_i_g come _r_o_o_t potrebbe
     essere la soluzione:



  ## llddccoonnffiigg aggiorna i link simbolici alla libreria condivisa.  _Q_u_e_s_t_o
  _p_o_t_r_e_b_b_e _n_o_n _e_s_s_e_r_e _n_e_c_e_s_s_a_r_i_o_.


    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 llnn --ss //uussrr//XX1111RR66//lliibb//lliibbXX1111..ssoo..66..11
     //uussrr//XX1111RR66//lliibb//lliibbXX1111..ssoo..66, come root.  Ci potrebbe dover essere
     seguito da un llddccoonnffiigg.



    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 _l_i_b_X_1_1_._s_o_._3 _-_>
     _l_i_b_X_1_1_._s_o_._3_._1_._0. Forse il software avr bisogno anche di un link
     del tipo _l_i_b_X_1_1_._s_o _-_> _l_i_b_X_1_1_._s_o_._3_._1_._0. Naturalmente, per creare un
     link "mancante", usate il comando llnn --ss lliibbXX1111..ssoo..33..11..00 lliibbXX1111..ssoo,
     _c_o_m_e _r_o_o_t.



    Alcuni pacchetti esigeranno l'installazione di versioni aggiornate
     di una o pi librerie. Per esempio, le versioni 4.x della suite
     _S_t_a_r_O_f_f_i_c_e della StarDivision GmbH erano famose per richiedere libc
     in versione 5.4.4 o successiva. Anche il pi recente _S_t_a_r_O_f_f_i_c_e 5.0
     non girer nemmeno dopo l'installazione con le nuove librerie glibc
     2.1. Fortunatamente, il pi nuovo _S_t_a_r_O_f_f_i_c_e 5.1 risolve tali
     problemi. Se avete una versione di _S_t_a_r_O_f_f_i_c_e 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).

     AAtttteennzziioonnee:: UUssaattee mmoollttaa ccaauutteellaa nneell ffaarree ccii,, ppooiicchh ppoottrreessttee
     rreennddeerree nnoonn ffuunnzziioonnaannttee iill vvoossttrroo ssiisstteemmaa ssee ccoommbbiinnaattee ddeeii
     ppaassttiiccccii..

     Potete trovare le librerie pi aggiornate presso Sunsite.


  77..22..  AAllttrrii pprroobblleemmii



    Uno script _P_e_r_l 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 _P_e_r_l  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, llnn --ss //uussrr//bbiinn//ppeerrll
  //uussrr//llooccaall//bbiinn//ppeerrll.


    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 _b_i_n_a_r_i _l_i_n_k_a_t_i
     _s_t_a_t_i_c_a_m_e_n_t_e. 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 _l_i_n_k_a_t_o _s_t_a_t_i_c_a_m_e_n_t_e dall'autore del pacchetto, o da un
  gruppo utenti Linux, pu essere il modo pi facile per effettuare
  delle riparazioni.



    Eseguendo uno script _c_o_n_f_i_g_u_r_e  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
     _c_o_n_f_i_g_u_r_e sbagliato, uno trovato da qualche altra parte nel path.
     Lanciate sempre _c_o_n_f_i_g_u_r_e come ..//ccoonnffiigguurree 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 _G_l_i_b_c _2 _H_O_W_T_O
     ``(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 _-_a_n_s_i 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 _s_e_t_u_i_d _r_o_o_t, per poter essere
     eseguiti con _p_r_i_v_i_l_e_g_i _d_i _r_o_o_t. Il comando per effettuare ci 
     cchhmmoodd uu++ss nnoommeeffiillee, _c_o_m_e _r_o_o_t (osservate che il programma deve gi
     essere di propriet di root). Questo ha l'effetto di impostare il
     bit _s_e_t_u_i_d 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 _a_c_c_e_s_s _d_e_n_i_e_d (accesso negato) ad un utente normale,
     sospettate che la causa sia questa.



     AAvvvveerrttiimmeennttoo:: Un programma con _s_e_t_u_i_d 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
     _s_e_t_u_i_d.



  77..33..  RRiittoocccchhii ee mmeessssaa aa ppuunnttoo


  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 _-_O_2 si sceglie il pi alto livello di
  ottimizzazione ed il flag _-_f_o_m_i_t_-_f_r_a_m_e_-_p_o_i_n_t_e_r provoca la generazione
  di un binario pi piccolo (sebbene il debugging sar cos
  disabilitato). PPeerr nnoonn ggiioocchheerreellllaattee ccoonn ttaallii ooppzziioonnii,, aa mmeennoo cchhee nnoonn
  ssaappppiiaattee ccoossaa ssttaattee ffaacceennddoo,, ee ccoommuunnqquuee nnoonn pprriimmaa ddii aavveerr ootttteennuuttoo uunn
  bbiinnaarriioo ffuunnzziioonnaannttee..



  77..44..  DDoovvee ttrroovvaarree mmaaggggiioorree aaiiuuttoo


  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8..  CCoonncclluussiioonnii

  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 (mmvv) in Xprog ed installatelo nella directory
  /usr/lib/X11/app-defaults _c_o_m_e _r_o_o_t. 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. _C_o_m_e _r_o_o_t, 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
  _d_o_c_u_m_e_n_t_a_z_i_o_n_e _d_i _m_a_n 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 _i_n_s_t_a_l_l 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, _c_o_m_e _r_o_o_t, 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 mmaakkee iinnssttaallll, e
  forse un mmaakkee iinnssttaallll..mmaann o un mmaakkee iinnssttaallll__mmaann. Se  cos, i file di
  documentazione README o INSTALL lo specificheranno.



  99..  PPrriimmoo eesseemmppiioo:: XXssccrraabbbbllee

  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



  _O_v_v_i_a_m_e_n_t_e _n_o_n _f_u_n_z_i_o_n__._._.



       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 _m_a_k_e 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:matt@belgarath.demon.co.uk> via
  e-mail, e scaricare _X_s_c_r_a_b_b_l_e dalla sua home page
  <http://www.belgarath.demon.co.uk/programs/index.html>.



              Scrabble  un marchio registrato dalla Milton Bradley Co., Inc.



  1100..  SSeeccoonnddoo eesseemmppiioo:: XXllooaaddiimmaaggee

  Questo esempio pone un problema pi facile. Il programma _x_l_o_a_d_i_m_a_g_e
  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, _t_a_r _x_z_v_f estrae i file dall'archivio. Il
  _m_a_k_e, 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 _x_l_o_a_d_i_m_a_g_e, _w_c_h_a_r___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'_i_n_c_l_u_d_e _s_t_d_l_i_b_._h, dopo tutto, non  necessario.

  A questo punto, la fase di compilazione procede senza nessun errore
  fatale. Il pacchetto _x_l_o_a_d_i_m_a_g_e funziona correttamente ora.



  1111..  TTeerrzzoo eesseemmppiioo:: FFoorrttuunnee

  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 _f_o_r_t_u_n_e 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 _f_o_r_t_u_n_e_._c, e nemmeno un ggrreepp ddiirreenntt la mostra in nessuno dei file
  sorgenti. Tuttavia, all'inizio di _f_o_r_t_u_n_e_._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 _d_i_r_e_n_t_._h  in _/_u_s_r_/_i_n_c_l_u_d_e.
  Effettivamente esiste un file _d_i_r_e_n_t_._h in _/_u_s_r_/_i_n_c_l_u_d_e, ma quel file
  non contiene la dichiarazione della struttura dirent. C', per, un
  riferimento ad un altro file _d_i_r_e_n_t_._h.



       #include <linux/dirent.h>



  Alla fine, andando in _/_u_s_r_/_i_n_c_l_u_d_e_/_l_i_n_u_x_/_d_i_r_e_n_t_._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___n_a_m_e_l_e_n, ma ci sono un paio di "candidati" come suo equivalente. Il
  pi probabile di essi  _d___r_e_c_l_e_n, poich questo membro della struttura
  probabilmente rappresenta la lunghezza di qualcosa ed  uno short
  integer. L'altra possibilit, _d___i_n_o, 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___n_a_m_e_l_e_n a _d___r_e_c_l_e_n. Proviamo di nuovo un _m_a_k_e _a_l_l.
  SSuucccceessssoo.. La compilazione finisce senza errori. Ora possiamo prenderci
  i nostri "brividi a buon mercato" da fortune.



  1122..  QQuuaarrttoo eesseemmppiioo:: HHeeaarrttss


  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:badger@phylo.life.uiuc.edu>. 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.

  _P_r_i_m_a _d_i _i_n_i_z_i_a_r_e_, _a_c_c_e_r_t_a_t_e_v_i _d_i _a_v_e_r_e _l_e _l_i_b_r_e_r_i_e motif o le lesstif
  installate.


  

  xxmmkkmmff

  mmaakkee



  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 ___t_t_y.

  mmaakkee



       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>



  mmaakkee



       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 _t_e_r_m_i_n_f_o e/o _t_e_r_m_c_a_p,
  piuttosto che l'obsoleto _t_e_r_m_l_i_b.

  Editiamo il Makefile.

  Linea 655:


       CURSES_LIBRARIES = -lcurses -ltermlib



  cambiamola in:


       CURSES_LIBRARIES = -lcurses -ltermcap



  mmaakkee



       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 _l_e_s_s_t_i_f  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



  mmaakkee



       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.)



  mmaakkee



  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!)



  

  _I_n_s_t_a_l_l_a_z_i_o_n_e_:

  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



  

  _E_s_e_c_u_z_i_o_n_e _d_i _p_r_o_v_a_:

  rreehhaasshh

  (Stiamo eseguendo la shell tcsh.)

  xxmmhheeaarrttss



       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 _r_o_o_t,

  ccdd //uussrr//llooccaall//lliibb

  mmkkddiirr hheeaarrttss

  ccdd !!$$

  Copiamo i file di distributor in questa directory.

  ccpp //hhoommee//uusseerrnnaammee//hheeaarrttss//hheeaarrttssdd ..

  ccpp //hhoommee//uusseerrnnaammee//hheeaarrttss//hheeaarrttss__ddiisstt ..

  ccpp //hhoommee//uusseerrnnaammee//hheeaarrttss//hheeaarrttss..iinnssttrr ..



  

  _L_a_n_c_i_a_m_o _u_n_'_a_l_t_r_a _e_s_e_c_u_z_i_o_n_e _d_i _p_r_o_v_a_.

  xxmmhheeaarrttss

  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 _r_o_o_t,

  cchhmmoodd uu++ss //uussrr//llooccaall//lliibb//hheeaarrttssdd

  cchhmmoodd uu++ss //uussrr//llooccaall//lliibb//hheeaarrttss__ddiisstt

  (Osserviamo che, come discusso precedentemente, i binari _s_u_i_d possono
  creare dei buchi di sicurezza.)

  xxmmhheeaarrttss

  _A_l_l_a _f_i_n_e _f_u_n_z_i_o_n_a_!


  _H_e_a_r_t_s  disponibile da Sunsite.



  1133..  QQuuiinnttoo eesseemmppiioo:: XXmmDDiippmmoonn



       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
  _d_i_p, il che lo rende inutile per tutti quelli, la maggioranza, che
  usano _c_h_a_t per collegarsi.

  Compilare XmDipmon non  un problema. XmDipmon si linka con le
  librerie _M_o_t_i_f, ma pu essere compilato, e funziona bene, anche con le
  _L_e_s_s_t_i_f. La sfida  di modificare il pacchetto per farlo funzionare
  con _c_h_a_t. 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 _-_p_i_d_f_i_l_e, il programma pu essere indotto, al suo
  avvio, a cercare un altro file, uno che esista solo dopo che un login
  con _c_h_a_t  stato effettuato con successo.  Il candidato pi ovvio  il
  file di lock del modem. Potremmo quindi provare a lanciare il
  programma con xxmmddiippmmoonn --ppiiddffiillee //vvaarr//lloocckk//LLCCKK....ttttyySS33 (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
  _d_e_m_o_n_e _d_i_p e dobbiamo invece fare in modo che controlli un processo
  che sia associato a _c_h_a_t o a _p_p_p.

  C' un solo file sorgente e fortunatamente  ben commentato.
  Scorrendo il file xmdipmon.c troviamo la funzione _g_e_t_P_r_o_c_F_i_l_e, 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 _p_p_p_d:


       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 _c_h_a_t
  pienamente funzionante.



  XmDipmon pu essere scaricato da Ripley Linux Tools.



  1144..  DDoovvee ttrroovvaarree aarrcchhiivvii ssoorrggeennttee

  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
  _s_u_b_s_c_r_i_b_e.

  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



  1155..  CCoonncclluussiioonnii

  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'aarrttee ddeellllaa ccoommppiillaazziioonnee ddeell ssooffttwwaarree.



  1166..  RRiiffeerriimmeennttii ee uulltteerriioorrii lleettttuurree



  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.]


  __________________

  TTrraadduuzziioonnii: 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 _i_n _i_t_a_l_i_a_n_o, 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>.



  1177..  CCrreeddiittii


  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/>.



