<!doctype linuxdoc system>
<!--    $Id: elf-howto.sgml,v 1.11 1995/09/13 11:38:25 dan Exp $         -->
<article>

<title>Il Linux ELF HOWTO
<author>Daniel Barlow <tt>&lt;daniel.barlow@sjc.ox.ac.uk&gt;</tt>
<date>v1.11, 13 September 1995

<abstract>
Traduzione a cura di Renato Favro, nos@maya.dei.unipd.it.
Questo documento descrive il modo per modificare il vostro sistema linux
per compilare e far girare i programmi che usano il formato binario ELF. Il
documento &egrave; diviso in tre parti: (1) Che cosa &egrave; l'ELF, e perch&egrave; e se &egrave; il
caso di implementarlo, (2) Come fare l'upgrade, e (3) che cosa si pu&ograve;
fare dopo l'upgrade.

</abstract>

<sect>Cosa &egrave; l'ELF? Un introduzione

<p>

<p> L'ELF (Executable and Linking Format) &egrave; un formato binario
originariamente sviluppato da USL (UNIX System Laboratories) e correntemente
usato nei sistemi operativi Solaris e System V Release 4. A causa della
maggiore flssibilit&agrave; rispetto al vecchio formato a.out, che linux
attualmente usa, gli sviluppatori di librerie per GCC e per C, hanno deciso
lo scorso anno di muoversi nella direzione di usare anche l'ELF come formato
binario standard.

Questa `migliore flessibilit&agrave;' si manifesta essenzialmente in due benefici
per il programmatore medio di applicazioni:

<itemize>

<item> E` molto pi&ugrave; semplice creare librerie condivise con l'ELF.
Usualmente, basta compilare tutti i file oggetto con <tt>-fPIC</tt>,
e poi fare il link con un comando come

<tscreen><verb> gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o 
</verb></tscreen>

Se questo sembra complicato, ovviamente &egrave; perch&egrave; non avete mai letto
la procedura equivalente per le librerie condivise usate dal sistema a.out,
che comporta compilare la libreria due volte, riservare lo spazio per
tutti i dati che si pensa saranno richiesti in futuro, e registrare quello
spazio degli indirizzi con una terza parte. (Il tutto &egrave; descritto in un
documento lungo 20 pagine --- vedere a
<url url=
"ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.16.tar.gz">
per i dettagli).

<item> Il caricamento dinamico (dynamic loading, cio&egrave; il meccanismo
usato dai programmi
che possono caricare vari moduli durante l'esecuzione) &egrave; molto pi&ugrave;
semplice. Questo &egrave; usato da Perl 5, Python, e il port di Java su Linux,
fra le altre cose. Altri suggerimenti per il caricamento dinamico
hanno incluso MUDs ultra veloci, dove il codice aggiuntivo pu&ograve; essere
compilato separatamente e il link pu&ograve; essere fatto mentre l'eseguibile
gira, senza dover far fermare e ripartire il programma.

</itemize>

<p>Detto questo, bisogna tener presente che l'ELF pu&ograve; essere un p&ograve; pi&ugrave;
lento. Le voci che si raccolgono in giro dicono tra l'1% e il 5%,
sebbene tutti i test attuali che sono stati condotti fino a questo momento,
indicano che la differenza &egrave; sufficientemente piccola per passare
inosservata nel `rumore' di altri eventi che possono avvenire nello stesso
tempo. Se si ha il TeX oppure una stampante o un convertitore Postscript,
si pu&ograve; leggere <tt/speed.comp-1.0.tar.gz/, che &egrave; disponibile da qualche
parte in SunSite. (?)

Il rallentamento deriva dal fatto che il codice delle librerie ELF deve
essere indipendente dalla posizione (questo &egrave; quello che <tt>-fPIC</tt>
st&agrave; ad indicare) e cos&igrave; un registro deve essere sacrificato per contenere
gli offset, il che implica un registro in meno per mantenere le variabili,
e comunque i processori 80x86 hanno una carenza di registri 
general-purpose di per s&egrave;.

<sect1> Che cosa ELF non &egrave;

<p> Esiste un certo numero di fraintendimenti riguardo a cosa l'ELF
far&agrave; per il proprio sistema:

<descrip>
<tag/ Non &egrave; una maniera per far girare programmi per SVR4 o per Solaris/

Sebbene l'ELF sia lo stesso tipo di `contenitore binario' usato da SVR4,
questo non significa che i programmi SVR4 diventino improvvisamente
eseguibili su di un Linux. La cosa &egrave; analoga al formato di un disco --- si
puossono tenere i programmi per Linux su di un disco formattato in MSDOS
o in MINIX, e  viceversa, ma questo non significa che questi sistemi 
diventino capaci di far girare l'uno i programmi dell'altro.

Teoricamente &egrave; possibile eseguire applicazioni per altri unix per processori
x86 sotto Linux, ma seguendo le istruzioni contenute in questo HOWTO
<em/non/ non si avr&agrave; questo  effetto.  Per questa esigenza, si provi a
guardare il modulo per il kernel iBCS (da qualche parte su 
<tt/tsx-11.mit.edu/) e si veda se questo coincide con le proprie esigenze.

<tag/Non &egrave; intrinsecamente pi&ugrave; piccolo o pi&ugrave; veloce/

Si pu&ograve; anche finire per avere dei binari pi&ugrave; piccoli tuttavia,
poich&egrave; si possono creare pi&ugrave; facilmente librerie condivise di codice comune
tra varie applicazioni. In generale, se si usano le stesse opzioni di
compilazione e il proprio codice binario risulta pi&ugrave; piccolo rispetto
a quanto avveniva con il sistema a.out, &egrave; pi&ugrave; verosimile che sia un caso
fortunato, oppure a causa di una versione del compilatore differente.
Per quanto riguarda la velocit&agrave;, ne sarei veramente sorpreso. Gli incrementi
di velocit&agrave; potrebbero verificarsi se il proprio codice binario risultasse
pi&ugrave; piccolo, a causa di un minor swapping, o di aree funzionali pi&ugrave; grandi
che riuscirebbero ad essere contenute nella cache.

<tag/Non richiede che vengano rimpiazzati tutti i codici binari sul
proprio sistema/

Alla fine della procedura qui descritta, si avr&agrave; un sistema capace di
compilare ed eseguire programmi sia in ELF che in a.out. I nuovi
programmi verranno compilati in ELF per default, sebbene questo possa
essere cambiato con uno switch sulla riga di comando del compilatore.
Esiste per la verit&agrave; una penalizzazione che riguarda la memoria, per
un sistema configurato per far girare un sistema misto ELF/a.out --- se
si hanno entrambe le famiglie di programmi che girano insieme, si hanno anche
due copie della libreria C nel core, e cos&igrave; via. Dalle informazioni che
ho avuto, la differenza di velocit&agrave; non &egrave; percettibile nell'uso normale
su di un sistema con 6Mb, (io certamente non ne ho notata in 8 Mb), cos&igrave;
difficilmente &egrave; un problema seccante. Si perde molta pi&ugrave; memoria ogni 
giorno, facendo girare programmi sovrabbondanti come Emacs, e programmi
statici come Mosaic/Netscape :-)

<tag/Non ha nulla a che fare con Tolkien/

O, almeno, non in questo contesto.

</descrip>

<sect1>  Perch&egrave; (non) ci si dovrebbe convertire a ELF

<p> Ci sono essenzialmente due motivi per fare l'upgrade del proprio sistema
per poter compilare ed eseguire il codice binario in ELF: il primo &egrave; la
migliore flessibilit&agrave; gi&agrave; spiegata, e il secondo &egrave; che, a causa del primo,
tutti quanti lo faranno. Le release future della libreria C e GCC, saranno
compilate unicamente per ELF, e ci si aspetta che altri sviluppatori si 
muoveranno verso l'ELF.

Piacevolmente per gli scopi di simmetria, ci sono anche due ragioni per non
convertirsi per ora. La prima &egrave; che le cose stanno ancora cambiando,
alcuni pacchetti (includendo la serie dei kernel `stabili' 1.2) richiedono
dei patch (delle modifiche) prima di poter essere compilati in ELF, e ci
possono essere dei bugs residui; si potrebbe aspettare finch&egrave; Linus stesso
si sar&agrave; covertito, per esempio.

La seconda &egrave; che sebbene la procedura di installazione descritta qui
sia un piccolo lavoro di per se stesso, (pu&ograve; infatti essere completato
in meno di un'ora, se non contiamo il tempo per tirare giu' il nuovo
software), un errore in qualunque momento puo' lasciare il sistema
in maniera che non sia pi&ugrave; capace di eseguire il bootstrap. Se
non ci si sente a proprio agio con l'eseguire l'upgrade delle librerie
condivise, e i comandi <tt>ldconfig</tt> e <tt>ldd</tt> non significano
nulla per chi legge, si pu&ograve; ottenere o aspettare di ottenere una
nuova distribuzione di Linux in ELF, fare il backup, reinstallare e
ripristinare il sistema, usando l'ELF. Poi (specialmente se il sistema
non &egrave; usato per applicazioni critiche), si pu&ograve; voler continuare comunque,
per imparare cose nuove.

Siete ancora con noi?

<sect> Installazione

<sect1> Background

<p> Lo scopo di questa conversione &egrave; quello di rimanere con un sistema
che sia in grado di costruire e di far girare i programmi in ELF e
col sistema a.out, con entrambe i tipi di programmi in grado di
trovare le rispettive famiglie di librerie condivise. Questo ovviamente 
richiede un p&ograve; pi&ugrave; di intelligenza nella ricerca delle librerie rispetto
al semplice `guarda in <tt>/lib</tt>, <tt>/usr/lib</tt> e in tutti i posti
in cui il programma &egrave; stato detto di cercare'.

La bestiola responsabile di ricercare le librerie in linux &egrave;
<tt>/lib/ld.so</tt>. Il compilatore ed il linker non inseriscono nel codice
i percorsi assoluti delle librerie dentro i programmi; inseriscono invece
il nome delle librerie, e il percorso assoluto di <tt/ld.so/, e lasciano
che sia <tt/ld.so/ ad associare il nome della libreria al percorso adeguato
al runtime. Questo ha un effetto molto importante --- significa che le
librerie che un programma usa, possono essere mosse verso altre directory
<em> senza ricompilare il programma </em>, semprech&egrave; a <tt/ld.so/ sia stato
detto di cercare nelle nuove directory. Questa &egrave; una funzionalit&agrave; essenziale
per l'operazione di scambio delle directory che segue.

Ne consegue che, naturalmente, ogni tentativo di cancellare o spostare
<tt>ld.so</tt> causer&agrave; il fatto che <em> ogni programma che sia linkato
dinamicamente sul sistema linux, cesser&agrave; di funzionare</em>. Questa &egrave;
generalmente ritenuta una cattiva cosa...

Per il codice binario in ELF, viene fornito un dynamic loader (caricatore
dinamico del codice) alternativo. Si chiama <tt>/lib/ld-linux.so.1</tt>,
e fa esattamente le stesse cose di <tt/ld.so/, ma per i programmi in ELF.
<tt/ld-linux.so.1/ usa gli stessi programmi e gli stessi file di supporto
(<tt/ldd/, <tt/ldconfig/, e <tt>/etc/ld.so.conf</tt>, che vengono usati
dal loader del formato a.out.

L'idea di base, poi, &egrave; che le cose che riguardano lo sviluppo in ELF
(compilatori, include files e librerie) vadano in
<tt>/usr/{bin,lib,include}</tt> dove attualmente si trovano quelle
che riguardano l'a.out, e che queste ultime vadano spostate in
<tt>/usr/i486-linuxaout/{bin,lib,include}</tt>.
<tt>/etc/ld.so.conf</tt> far&agrave; una lista di tutti i posti dove ci si
pu&ograve; aspettare di trovare una libreria, e <tt/ldconfig/ &egrave; abbastanza
intelligente da distinguere tra le varianti di ELF e di a.out.

Ci sono un paio di eccezioni al piazzamento delle librerie, tuttavia.

<itemize>

<item> Alcuni vecchi programmi sono stati costruiti senza l'uso di
<tt/ld.so/. Questi cesseranno di funzionare se le loro librerie saranno
spostate. In questo modo, <tt/libc.so*/ e <tt/libm.so*/ devono rimanere
dove stanno in <tt>/lib</tt>, e le versioni in ELF avranno il loro major
number aumentato, in maniera da non sovrascrivere le versioni per 
a.out. Le vecchie librerie per X (precedenti alla versione 6), &egrave; meglio
lasciarle dove stanno, sebbene le pi&ugrave; nuove (<tt/libX*.so.6/) debbano essere
spostate. Lo spostamento delle vecchie librerie causer&agrave; un apparente
malfunzionamento dei programmi xview, mentre non spostare le nuove librerie,
causer&agrave; la sovrascrittura quando si installeranno le librerie in ELF per
X.

Se si hanno programmi non-ld.so che richiedono altre librerie
rispetto a quelle gi&agrave; citate, (se si sa quali programmi sono, si pu&ograve;
far girare ldd su di loro per capire di quali librerie abbiano
bisogno <em/prima/ di rovinarli), allora si hanno essenzialmente due
possibilit&agrave;. La prima &egrave; che si possono estrarre i file tar in una directory
temporanea, controllare se le proprie preziose librerie saranno sovrascritte,
e, se cos&igrave; fosse, si sposter&agrave; la versione in ELF della libreria in,
diciamo, <tt>/usr/i486-linux/lib</tt> invece che <tt>/lib</tt>.
Sia sia sicuri che il proprio <tt/ld.so.conf/ abbia 
<tt>/usr/i486-linux/lib</tt>, e si faccia girare <tt/ldconfig/
e non ci si pensi pi&ugrave;. La seconda cosa &egrave; che si pu&ograve;  ricompilare o acquisire una
copia pi&ugrave; recente del programma che crea questa seccatura. Questa
non sarebbe affatto una cattiva idea, se possibile.

<item> Se si ha <tt>/usr</tt> e <tt>/</tt> su differenti partizioni,
sar&agrave; necessario muovere almeno alcune delle librerie in <tt>/lib</tt>
da qualche parte sul root disk, non in <tt>/usr</tt>. Si pu&ograve; sia
identificare i programmi necessari al system startup o quando si &egrave; in
modo single user (singolo utente), e trovare le librerie che usano, oppure
pu&ograve; dipendere dal vostro integratore del sistema o della distribuzione,
che pu&ograve; aver gi&agrave; fatto questo per voi, e semplicemente spostare tutte
(beh... alcune. Si veda quanto gi&agrave; detto per le eccezioni) le librerie
da <tt>/lib</tt> a <tt>/lib-aout</tt>.

</itemize>

<sect1> Prima di partire --- Note e diffide

<p>
<itemize>

<item> E` necessario che sul proprio sistema giri un kernel posteriore
alla versione 1.1.52 <bf>con il supporto per il formato binario ELF</bf>.

<item> E` molto raccomandabile preparare o procurarsi dei dischi di
root/boot, ad esempio come quelli di Slackware. Probabilmente non se ne
avr&agrave; bisogno, ma se succede di averne un paio e ci si ritrova sprovvisti, ci prenderemmo
a calci da soli. Seguendo questa attitudine del tipo `prevenire &egrave; meglio
che curare', possono essere d'aiuto per ogni situazione scomoda in cui
si pu&ograve; finire, delle copie linkate staticamente di <tt/mv/, <tt/ln/, e forse
anche di altre utility per la manipolazione dei file (sebbene di fatto
possa essere fatto tutto quello di cui si ha <em>bisogno</em> con le
possibilit&agrave; intrinseche della shell), per ogni situazione scomoda
in cui si pu&ograve; finire.

<item> Se avete seguito lo sviluppo dell'ELF, potete avere le librerie
ELF in <tt>/lib/elf</tt> (tipicamente <tt>libc.so.4</tt> e compagnia varia).
Le applicazioni costruite in questa maniera devono essere ricostruite,
e poi la directory rimossa. Non &egrave; necessario avere una directory
<tt>/lib/elf</tt>!

<item> La maggior parte delle installazioni Linux di questi giorni, hanno
aderito al `FSSTND' standard file system, ma senza dubbio ci sono ancora
dei sistemi che non seguono lo standard. Se si vedono referenze a
<tt>/sbin/</tt><em>qualcosa</em> e non si ha una directory <tt>/sbin</tt>,
propabilmente si troveranno i programmi relativi in
<tt>/bin</tt> o in <tt>/etc/</tt>.

</itemize>

<sect1> Si avr&agrave; bisogno di...

<p> I seguenti pacchetti sono disponibili a <url
url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/"> e a  <url
url="ftp://sunsite.unc.edu/pub/Linux/GCC/">. Entrambe i siti sono
ampiamente distribuiti in giro per il mondo; per favore, prendetevi il tempo
necessario per cercare il sito pi&ugrave; vicino a voi. E` pi&ugrave; veloce per voi
e per chiunque altro.

Questi pacchetti (sia la versione mostrata qui che qualunque altra successiva)
sono richiesti. Scaricate e leggete anche le varie release notes per ciascuno
di essi: questi sono i file chiamati <tt/release./<em/packagename/.
Questo specialmente se si scaricano versioni pi&ugrave; recenti di quelle
descritte qui, poich&egrave; la procedura pu&ograve; essere cambiata.

<itemize>

<item> <tt/ld.so-1.7.3.tar.gz/ --- il nuovo linker dinamico 

<item> <tt/libc-5.0.9.bin.tar.gz/ --- le immagini ELF condivise per
la libreria C e i suoi amici (<tt/m/ (maths), <tt/termcap/, <tt/gdbm/, e
cos&igrave; via),  pi&ugrave; le librerie statiche corrispondenti e gli include files
necessari per compilare i programmi con queste. libc 5.2.qualcosa potrebbe
essere rilasciata durante la vita di questo HOWTO, ed &egrave; notevolmente 
differente dalla versione 5.0.9; se si intende installarla, si procede
per conto proprio, ma io raccomando di installare prima la 5.0.9 e poi
installare `sopra' la versione successiva. Ci sono molte parti della
5.0.9 che non sono incluse nella 5.2.x, per le quali i canali di
distribuzione non sono ancora predisposti completamente.

<item> <tt/gcc-2.7.0.bin.tar.gz/ --- il compilatore C in ELF. Include
anche un compilatore C in a.out che capisce il nuovo ormato delle directory.

<item> <tt/binutils-2.5.2l.17.bin.tar.gz/ --- le utility binarie della GNU
per Linux. questi sono programmi come <tt/gas/, <tt/ld/, <tt/strings/ e cos&igrave;
via, la maggior parte dei quali sono richiesti per far funzionare il
compilatore C.

</itemize>

<sect1> Ridisponendo il proprio filesystem

<p> Bene.... Si noti che in tutto quel che segue, quando io dico
`si rimuova', naturalmente intendo `si faccia un backup e poi si rimuova' :-).
Inoltre, queste istruzioni si applicano direttamente soltanto alle persone
che non hanno gi&agrave;  smanettato con l'ELF --- quelli che ci si aspetta abbiano
gi&agrave; la capacit&agrave; di adattare le cose in modo appropriato. Andiamo!

<enum>
<item> Creare le nuove directory  verso cui si sposteranno le cose di a.out
<tscreen><code>
mkdir -p /usr/i486-linuxaout/bin
mkdir -p /usr/i486-linuxaout/include
mkdir -p /usr/i486-linuxaout/lib
mkdir /lib-aout
</code></tscreen>

<item> Si scompatti il pacchetto del linker dinamico <tt>ld.so-1.7.3</tt>
nella directory in cui di solito si mette il codice sorgente, poi si legga
lo script <tt>ld.so-1.7.3/instldso.sh</tt> appena estratto.
Se si ha un sistema realmente standard, &egrave; sufficiente farlo girare
digitando <tt>sh instldso.sh</tt>, ma se si ha qualcosa di insolito
allora si faccia l'installazione a mano. `Qualcosa di insolito' comprende

<itemize>

<item> usare zsh come shell (alcune versioni di zsh definiscono 
<tt/&dollar;VERSION/, il  che sembra confondere <tt/instldso.sh/) 

<item> avere  link simbolici da <tt>/lib/elf</tt> a <tt>/lib</tt>
(il che non &egrave; ncessario, ma si possono aver avuto delle valide ragioni per
farlo se si &egrave; seguito lo sviluppo dell'ELF).

</itemize>

<item> Si editi <tt>/etc/ld.so.conf</tt> per aggiungere le nuove directory
<tt>/usr/i486-linuxaout/lib</tt> (e <tt>/lib-aout</tt> se si pensa di averne
bisogno). Poi si faccia girare <tt>/sbin/ldconfig -v</tt> per controllare
che sono state caricate le nuove directory.

<item> Si muovano tutte le librerie a.out da <tt>/usr/*/lib</tt> a
<tt>/usr/i486-linuxaout/lib</tt>. Si  noti che ho scritto `librerie'
non `qualunque cosa'. Quindi si intende i file che rispondono al nome
di <tt/lib*.so*/ , <tt/lib*.sa*/, o <tt/lib*.a/. Non si incominci a
spostare <tt>/usr/lib/gcc-lib</tt> o niente di sciocco come questo in
giro.

<item> Adesso si guardi a <tt>/lib</tt>. Si lasci intatto <tt/libc.so*/,
<tt/libm.so*/, e <tt/libdl.so*/. Se si hano link simbolici a librerie X
(<tt/libX*.so.3*/) lasciate li anche questi --- XView e qualche altro
pacchetto potrebbe averne bisogno. Si lasci <tt/ld.so*/, <tt/ld-linux.so*/
e qualunque altro file che comincia con <tt/ld/. Per le librerie rimanenti,
(se ne avete qualcuna): se si ha <tt>/usr</tt> sulla partizione root,
si mettano in <tt>/usr/i486-linuxaout/lib</tt>. Se si ha <tt>/usr</tt>
montata separatamente, si mettano in <tt>/lib-aout</tt>. Adesso si
faccia girare <tt/ldconfig -v/

<item> Si rimuova la directory <tt>/usr/lib/ldscripts</tt> se &egrave; li,
per la preparazione all'installazione delle utility binarie (che
la ricreeranno).

<item> Si rimuova qualsiasi copia di <tt>ld</tt> e di <tt>as</tt>
(<em>eccetto</em> <tt>ld86</tt> e <tt>as86</tt>) che si pu&ograve; trovare in
<tt>/usr/bin</tt>.

<item> Alcune versioni del GNU tar sembrano avere problemi riguardo 
ai link simbolici nella directory di destinazione. Si hanno due possibilit&agrave;
a questo punto:

<enum> 

<item> (perferibilmente) Si usi <tt/cpio/ invece di <tt/tar/, poich&egrave; non
ha questo problema. <tt>zcat /ovunque/sia/stato/messo/libc-5.0.9.tar.gz | cpio
-iv</tt> &egrave; l'incantesimo magico qui, che deve essere eseguito dalla
directory root.

<item> (se non si ha installato cpio) Prima di installare le immagini
della libc, si pu&ograve; andare in <tt>/usr/include</tt> e rimuovere alcune
parti.

Questa &egrave; brutta.  Molti pacchetti (come ncurses) sono installati
in <tt>/usr/include</tt> dai manutentori della distribuzione  e <em>non</em>
sono fornite con la libreria C. Si faccia un backup dell'albero della
directory <tt>/usr/include</tt>, si usi <tt>tar tzf</tt> per vedere
cosa c'&egrave; nell'archivio prima di scompattarlo, poi cancellare le poche cose
di <tt>/usr/include</tt> che sono al momento contenute. Poi si
scompatti il file <tt>libc-5.0.9.bin.tar.gz </tt> dalla directory root.

</enum>

<item> installare il pacchettocon le utility binarie. <tt>tar -xvzf 
binutils-2.5.2.l17.bin.tar.gz -C / </tt> &egrave; una buona maniera per farlo.

<item> A questo punto &egrave; stato installato tutto quello che serve per
far girare gli eseguibili in ELF. Gli esperti medici raccomandano che
i lavoratori VDU (VDU &egrave; un acronimo per Video Display Unit, quindi si 
indicano qui i lavoratori che usano qualunque dispositivo con un monitor
N.d.T.) prendano delle pause regolari dallo schermo; questo sarebbe un
momento opportuno. Non si dimentichi quello che si stava facendo tuttavia,
a seconda della versione di gcc che si stava precedentemente usando,
&egrave; possibile che non si sia in grado di compilare programmi in formato a.out,
fino a che non si installa il nuovo gcc.

<item> fare il backup e cancellare tutto in <tt>
/usr/lib/gcc-lib/{i486-linux, i486-linuxelf, i486-linuxaout}/ </tt> Se
si usa un driver <tt/gcc/ non standard, (per esempio se si usa il GNU ADA),
si copi anche quello in un posto sicuro. Poi si installi in pacchetto gcc,
di nuovo scompattando il tutto dalla directory root. 

<item> Alcuni programmi (solitamente vari programmi per X) usano
<tt>/lib/cpp</tt>, che generalmente sotto linux &egrave; un link a
<tt>/usr/lib/gcc-lib/i486-linux/</tt><em/version/<tt>/cpp</tt>. Siccome
ilpasso precedente ha cancellato qualsiasi versione a cui <tt/cpp/
stava puntando, bisogner&agrave; ricreare il link:

<tscreen><verb>
$ cd /lib
$ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .
</verb></tscreen>

<item> La gente di FSSTND hanno ancora una volta giustificato la loro 
esistenza muovendo i file <tt/utmp/ e <tt/wtmp/ da <tt>/var/adm</tt>
a <tt>/var/run</tt> e a <tt>/var/log</tt> rispettivamente. Bisogner&agrave;
aggiungere alcuni link che dipendono da dove attualmente questi risiedono,
e pu&ograve; essere necessario creare le directory 
<tt>/var/log</tt> and <tt>/var/adm</tt>. Io ho riprodotto qui sotto
l'output del comando <tt/ls -l/ delle parti appropriate del mio sistema:

<tscreen><verb>
$ ls -ld /var/adm /var/log /var/run /var/log/*tmp /var/run/*tmp
lrwxrwxrwx   1 root     root            3 May 24 05:53 /var/adm -> log/
drwxr-xr-x   9 root     root         1024 Aug 13 23:17 /var/log/
lrwxrwxrwx   1 root     root           11 Aug 13 23:17 /var/log/utmp -> ../run/utmp
-rw-r--r--   1 root     root       451472 Aug 13 23:00 /var/log/wtmp
drwxr-xr-x   2 root     root         1024 Aug 13 23:17 /var/run/
-rw-r--r--   1 root     root          448 Aug 13 23:00 /var/run/utmp
</verb></tscreen>

Si controlli il FSSTND (dagli archivi LDP come <url
url="ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/">) per la storia completa.

<item> Questo passo &egrave; opzionale. Se si ha intenzione di continuare a
compilare programmi in formato a.out, questo &egrave; il momento ideale per
installare libc.so 4.7 <em/x/. Lo si scompatti dalla directory root,
poich&egrave; a questo punto si &egrave; senz'altro in grado di farlo senza
ulteriori spiegazioni.

</enum>

<bf> Fatto! </bf> Semplici test che si possono provare sono: 

<tscreen><code>
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs
gcc version 2.7.0
$ gcc -v -b i486-linuxaout
Reading specs from /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs
gcc version 2.7.0
$ ld -V
ld version cygnus/linux-2.5.2l.14 (with BFD cygnus/linux-2.5.2l.11)
  Supported emulations:
   elf_i386
   i386linux
   i386coff
</code></tscreen>

seguiti ovviamente dal tradizionale programma ``Hello World''. Si provi
con <tt/gcc/ e con <tt/gcc -b i486-linuxaout/ per verificare che 
sia il compilatore ELF, sia il compilatore a.out sono configurati
correttamente.

<sect1> Come dovrebbe sembrare (schema della struttura delle directory)

<p> Questa &egrave; una guida deliberatamente vaga a che cosa sono i files
che avete appena installato. Pu&ograve; essere utile per la soluzione di problemi,
o per decidere cosa cancellare.

<sect2><tt> /lib </tt>
<p><itemize>

<item> Linker dinamici <tt/ld.so/ (a.out) e <tt/ld-linux.so.1/ (ELF).
Entrambe possono essere link simbolici, ma siate sicuri che i file
a cui puntano esistano.

<item> Librerie condivise di base <tt/libc.so.4/, <tt/libm.so.4/ (a.out)
Questi sono link simbolici, ma curate che anche questi puntino a file
esistenti.

<item> Librerie condivise di base <tt/libc.so.5/, <tt/libm.so.5/,
<tt/libdl.so.1/, <tt/libcurses.so.1/, <tt/libtermcap.so.2/, (ELF).
Anche questi sono link simbolici.

<item> <em/Un mucchio/ di link simbolici. Per ciascuna libreria, dovrebbe
esserci un file attuale (per esempio <tt/libc.so.5.0.9/), un link simbolico
che punta allo stesso con solo il major number della versione (<tt/libc.so.5/)
ed un link simbolico che punta a quest'ultimo senza numero di versione
(<tt/libc.so/). In questa maniera:

<tscreen><code>
lrwxrwxrwx   1 root  root      9 May 24 05:52 libc.so -> libc.so.5
lrwxrwxrwx   1 root  root     13 Aug 25 12:48 libc.so.5 -> libc.so.5.0.9
-rwxr-xr-x   1 bin   bin  562683 May 19 04:47 libc.so.5.0.9
</code></tscreen>

</itemize>

<sect2><tt>/usr/lib</tt>
<p><itemize>

<item> Tutti i file che non sono librerie e che esistevano gi&agrave; in precedenza.

<item> <tt/libbfd.so*/,<tt/libdb.so*/, <tt/libgdbm.so*/, le librerie
condivise di ELF. Tutte consistono di tre file come spiegato in precedenza
nella sezione <tt>/lib</tt>.

<item>
<tt/libbsd.a/, <tt/libgmon.a/, <tt/libldso.a/, <tt/libmcheck.a/,
<tt/libieee.a/, <tt/libmcheck.a/ ed un <tt/lib*.a/ file per ogni
libreria condivisa in ELF. Quelli che duplicano le librerie condivise
possono non essere estremamente utili per la maggioranza delle persone
--- quando si usa l'ELF si pu&ograve; usare lo switch <tt/gcc -g/ con le 
librerie condivise, cos&igrave; non ha pi&ugrave; molto senso fare compilazioni statiche.

<item> <tt/crt0.o/, <tt/gcrt0.o/.  a.out, che sono i file di `inizio di
programma';uno di questi &egrave;  linkato come primo file in ogni programma
di tipo a.out, a meno che non si prendano degli accorgimentio per evitarlo.

<item> <tt/crt1.o/, <tt/crtbegin.o/, <tt/crtbeginS.o/, <tt/crtend.o/,
<tt/crtendS.o/, <tt/crti.o/, <tt/crtn.o/, <tt/gcrt1.o/.  I file di startup
dell'ELF. Questi fanno una cosa simile a quanto appena visto per i
file <tt/*crt0.o/

</itemize>

<sect2><tt> /usr/lib/ldscripts </tt>

<p><itemize>

<item> Questo &egrave; dove risiede lo script driver per <tt/ld/, come suggerisce
il nome stesso. Dovrebbe apparire come

<tscreen><code>
$ ls /usr/lib/ldscripts/
elf_i386.x      elf_i386.xs     i386coff.xn     i386linux.xbn
elf_i386.xbn    elf_i386.xu     i386coff.xr     i386linux.xn
elf_i386.xn     i386coff.x      i386coff.xu     i386linux.xr
elf_i386.xr     i386coff.xbn    i386linux.x     i386linux.xu
</code></tscreen>
</itemize>

<sect2><tt>/usr/i486-linux/bin</tt>

<p><itemize> 

<item> <tt/ar/, <tt/as/, <tt/gasp/, <tt/ld/, <tt/nm/, <tt/ranlib/,
<tt/strip/.  Questi attualmente sono tutti link simbolici alle utility 
binarie in <tt>/usr/bin</tt>
</itemize>

<sect2><tt>/usr/i486-linuxaout/bin</tt>

<p><itemize> 

<item> <tt/as/ --- L'assembler per l'a.out, e <tt/gasp/, il suo preprocesore
delle macro

<item> <tt/ar/, <tt/ld/, <tt/nm/, <tt/ranlib/, <tt/strip/ --- link simbolici
alle utility binarie in <tt>/usr/bin</tt>

</itemize>

<sect2><tt>/usr/i486-linux/lib</tt>

<p><itemize>
<item> <tt>ldscripts</tt> &egrave; un link simbolico a <tt>/usr/lib/ldscripts</tt>.
</itemize>

<sect2><tt>/usr/i486-linuxaout/lib</tt>
<p><itemize>

<item> <tt/lib*.so*/. librerie condivise per a.out. Sono necesarie per  
far girare programmi in formato a.out.

<item> <tt/lib*.sa/. mozziconi di librerie per il formato a.out.  
Necessarie per compilare programmi a.out. Se non si intende farlo,
si possono tranquillamente rimuoverle.

<item> <tt/lib*.a/. librerie statiche per il formato a.out.  Necessarie
per compilare programmi statici in a.out (ciao&egrave; quando si compila con
<tt/-g/). Di nuovo, si possono rimuovere se non si ha questa intenzione.

<item> <tt/ldscripts/ &egrave; un link simbilico a <tt>/usr/lib/ldscripts</tt>
</itemize>

<sect2><tt>/usr/lib/gcc-lib/i486-linux/2.7.0</tt>

<p><itemize>
<item> Questa directory contiene una versione di gcc 2.7.0 predisposta
per compilare programmi in ELF.
</itemize>

<sect2><tt>/usr/lib/gcc-lib/i486-linuxaout/2.7.0</tt>

<p><itemize>
<item> Questa directoryy contiene una versione del gcc 2.7.0, configurata
per compilare programmi in a.out, che riconosce la nuova struttura delle
directory. Se non si ha intenzione di compilare nulla in format a.out,
si pu&ograve; cancellare questa directory. liberando in questo modo 4Mb.
</itemize>

<sect1> Errori comuni (Niente Panico!)

<p> ... in grandi lettere amichevoli.

<descrip>

<tag/ Avete spostato le cose sbagliate e non funziona nulla./

Avete ancora una shell in grado di girare, tuttavia, e con un p&ograve; di ingenuit&agrave;
potete fare un sacco di cose con le caratteristiche intrinseche della shell.
Ricordate che <tt>echo *</tt> &egrave; un sostituto accettabile per <tt/ls/,
e che <tt/echo &gt;&gt;filename/ pu&ograve; essere usato per aggiungere linee
ad un file. Inoltre non dimenticate che <tt/ldconfig/ &egrave; linkato staticamente.
Se avete spostato, ad esempio, <tt/libc.so.4/ in <tt>/lib-aout</tt>
erroneamente, potete fare <tt>echo &dquot;lib-aout&dquot;
&gt;&gt;/etc/ld.so.conf ; ldconfig -v</tt> ed essere di nuovo a posto.
se avete spostato  <tt>/lib/ld.so</tt> potete essere capaci di
fare <tt>sln /stupido/posto/ld.so /lib/ld.so</tt>, se avete una copia
di ln linkata staticamente, e probabilmente vi ritroverete con tutto
a posto.

<tag><tt> no such file or directory: /usr/bin/gcc </tt></tag>

... quando sapete che <em>esiste</em> quel file.  Questo solitamente
significa che il loader dinamico dell'ELF <tt>/lib/ld-linux.so.1</tt>
non &egrave; installato, o non &egrave; leggibile per qualche motivo. Dovreste
averlo installato al passo 2 in precedenza.

<tag><tt> not a ZMAGIC file, skipping </tt></tag>

dal comando <tt>ldconfig</tt>.  Questo &egrave; perch&egrave; avete una vecchia versione
del pacchetto ld.so, cos&igrave; dovete prenderne una nuova. Riguardate il  passo
2dell'installazione.

<tag><tt> bad address </tt></tag>

tentando di far girare qualunque cosa in ELF. State usando il kernel
1.3.<em>x</em>, dove <em>x</em>&lt;3. Fate un upgrade alla versione 1.3.3
oppure fate un downgrade a qualche versione 1.2.<em>x</em>

<tag><tt> _setutent: Can't open utmp file </tt></tag>

Questo messaggio &egrave; spesso visto in multipli di tre quando si fa partire un
xterm. Andate avanti e leggete il papiro sul FSSTND verso la fine della
procedura di installazione.

<tag><tt> gcc: installation problem, cannot exec <em>qualcosa</em>: No such file or directory</tt>
</tag>

Quando si tenta di fare una compilazione in a.out (<em>qualcosa</em> in
genere sono <tt>cpp</tt> o <tt>cc1</tt>). Pu&ograve; essere sia una cosa corretta,
oppure verosimilmente avete digitato

<tscreen><verb>
$ gcc -b -i486-linuxaout
</verb></tscreen>

quando avreste dovuto digitare

<tscreen><verb>
$ gcc -b i486-linuxaout
</verb></tscreen>

Notate che `i486' <em>non</em> inizia con un meno.

</descrip>

<sect>Costruire programmi in ELF

<sect1> Programmi ordinari

<p> Per costruire programmi in ELF, usate <tt>gcc</tt> come sempre.
Per costruire programmi in formato a.out usate la forma
<tt>gcc -b i486-linuxaout </tt>.

<tscreen><code>
$ cat >hello.c
main() { printf("hello, world\n"); }
^D
$ gcc -o hello hello.c
$ file hello
hello: ELF 32-bit LSB executable i386 (386 and up) Version 1
$ ./hello
hello, world
</code></tscreen>

Questo &egrave; forse il momento appropriato per rispondere alla domanda
``se il compilatore in a.out per default produce un programma chiamato
<tt>a.out</tt>, che nome gli dar&agrave; un compilatore ELF?''. Sempre
<tt>a.out</tt> &egrave; la risposta. Noia, noia, noia, ... <tt> :-)</tt>

<sect1> Costruire le librerie

<p> Per costruire libfoo.so come libreria condivisa, i passi di base
da compiere assomigliano a questi:

<tscreen><code>
$ gcc -fPIC -c *.c
$ gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 *.o
$ ln -s libfoo.so.1.0 libfoo.so.1
$ ln -s libfoo.so.1 libfoo.so
$ export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
</code></tscreen>

questo generer&agrave; una libreria condivisa chiamata <tt>libfoo.so.1.0</tt>, e
il collegamento appropriato per ld (<tt>libfoo.so</tt>) e il linker dinamico
(<tt>libfoo.so.1</tt>) per trovarla. Per provare, aggiungiamo
la directory corrente a <tt/LD_LIBRARY_PATH/.

Una volta contenti che la libreria funziona, bisogna spostarla, per esempio,
in <tt>/usr/local/lib</tt>, e ricreare il link appropriato.
Si noti che il link <tt>libfoo.so</tt> deve puntare a 
<tt>libfoo.so.1</tt>,  cos&igrave; che non c'&egrave; bisogno di aggiornamenti ad
ogni cambio della versione del minor number. il link da <tt/libfoo.so.1/ a
<tt/libfoo.so.1.0/ &egrave; mantenuto a posto da <tt>ldconfig</tt>, che
sulla maggior parte dei sistemi &egrave;  fatto girare automaticamente al
bootstrap.

<tscreen><code>
$ su
# cp libfoo.so.1.0 /usr/local/lib
# /sbin/ldconfig
# ( cd /usr/local/lib ; ln -s libfoo.so.1 libfoo.so )
</code></tscreen>

<sect1>Programmi con il dynamic loading

<p> Questo argomento &egrave; trattato estensivamente nel documento di H. J. Lu 
`ELF programming' e nella pagina del manuale <tt>dlopen(3)</tt> 
che pu&ograve;  essere trovata nel pacchetto ld.so. Qui c'&egrave; un piccolo esempio:
fatene il link con <tt>-ldl</tt>

<tscreen><code>
#include <dlfcn.h>
#include <stdio.h>

main()
{
  void *libc;
  void (*printf_call)();

  if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
  {
    printf_call=dlsym(libc,"printf");
    (*printf_call)("hello, world\n");
  }

}
</code></tscreen>

<sect1>Debugging

<!-- This needs exploring more fully at some stage -->

<p> La vostra copia esistente del <tt/gdb/ funzioner&agrave; prevalentemente
senza cambiamenti, con i programmi in ELF.
La nuova versione nella directory <tt/GCC/ su tsx-11 &egrave; ritenuta migliore
per fare il debugging dei programmi che usano le librerie condivise
e il dinamic loading, e anche per capire i core dump dei programmi in ELF.

Si noti che la serie di kernel 1.2 non possono generara i core dump
dai programmi in ELF in nessun modo. La serie 1.3 invece pu&ograve;.

<sect>Patch e codice binario vario

<p> A questo punto della procedura, &egrave; possibile fermarsi, se si vuole.
Abbiamo installato tutto quello che &egrave; necessario per compilare e far
girare i programmi in ELF.

Si pu&ograve; voler ricostruire alcuni programmi in ELF, sia per scopi di
`pulizia' sia per minimizzare l'uso della memoria. per la maggior
parte delle applicazioni end-user (cio&egrave; per l'utente finale), questo
&egrave;  molto semplice; alcuni pacchetti tuttavia assumono troppe informazioni
riguardo al sistema su cui girano, e possono fallire a causa di uno o pi&ugrave; di
questi motivi:
<itemize>

<item>Convenzioni differenti per quanto riguarda il carattere di
sottolineatura in assembler: nel formato a.out, le labels esterne sono
precedute da <tt>_</tt> , mentre in un eseguibile ELF no. Questo non f&agrave;
differenza fino a che non si integra codice assembler scritto a mano:
tutte le labels della forma <tt>_foo</tt>, devono essere tradotte in
<tt>foo</tt> o (se si vuole fare codice portatile)  in <tt/EXTERNAL(foo)/
dove <tt/EXTERNAL/ &egrave; una qualche macro che ritorna il suo argomento
(se <tt/__ELF/ &egrave; definito) oppure <tt/_/ concatenato con il suo
argomento se non &egrave; cos&igrave;.


<item>Differenze nella libc 5 dalla libc 4. L'interfaccia verso il
supporto locale &egrave; cambiato, per dirne una.

<item>L'applicazione o il processo di costruzione del codice, che
dipende dalla conoscenza del formato binario usato, --- emacs per esempio
copia l'immagine della sua memoria su disco in formato eseguibile, 
cos&igrave; ovviamente ha bisogno di sapere in che formato sono i vostri eseguibili.

<item>L'applicazione consiste di (oppure usa) le librerie condivise (X11
&egrave; un esempio ovvio). Queste ovviamente avranno bisogno di
qualche cambiamento per accomodare il metodo differente di creazione
delle librerie in ELF.

</itemize>

Adogni modo, ecco due liste: la prima &egrave; di programmi che hanno bisogno
di cambiamenti per l'ELF, dove i cambiamenti sono gi&agrave; stati fatti
(cio&egrave; avete bisogno di nuove versioni per compilarle come ELF),
e la seconda &egrave; di programmi che ancora hanno bisogno di patch da terze
parti.

<sect1>Upgrade:
<p>
<itemize> 

<item> <bf>Dosemu</bf>.  Il modulo di tre dei quattro alberi del corrente
albero dello sviluppo (non chiedere... meglio collegarsi direttamente
alla linux-msdos mailing list) del dosemu funziona con l'ELF. Non
c'&egrave; bisogno di diventare matti con il Makefile. Versioni correnti
del dosemu sono disponibili a <url
url="ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/">

<item> <bf>Emacs</bf>.  Emacs ha una procedura di costruzione che comprende
il far girare una versione minima di se stesso, caricare tutto il codice
utile come lisp, e poi scaricare la sua immagine in memoria di nuovo
su disco come un file eseguibile. (FSF) Emacs 19.29 e XEmacs 19.12
(che in precedenza si chiamava Lucid Emacs) possono entrambe capire
se si sta usando l'ELF e fare le cose giuste automaticamente.

<item> <bf>MAKEDEV</bf>. In alcune implementazioni, questa utility
rimuove i device esistenti prima di ricrearli. Questa &egrave; una brutta notizia
se succede di toccare <tt>/dev/zero</tt>, poich&egrave; questo device
&egrave; necessario per le operazioni di tutti i programmi in ELF. 
Si controlli il pacchetto util-linux per una versione corretta.

<item> <bf>perl 5.001</bf>. Perl 5.00 pi&ugrave; i patch ``ufficialmente non
ufficiali'' a-e, si compila senza modifiche sui sistemi con l'ELF,
comprendendo il dynamic loading. I patch sono disponibili da
<tt>ftp.metronet.com</tt> oppure da <tt>ftp.wpi.edu</tt>

<item> Il programma <tt/cal/ in <bf>util-linux 2.2</bf> non funziona.
Si faccia un upgrade alla
<url url="ftp://tsx-11.mit.edu/pub/linux/packages/utils"
name="versione 2.4"> o successiva.  

<item> <bf>XFree86</bf>.  XFree86 3.1.2 esiste sia in formato ELF
che in formato a.out. Si faccia <tt/ftp/ a <tt/ftp.xfree86.org/, 
e dopo aver letto il messaggio `too many users' che &egrave; praticamente sicuro
otterrete, e trovate il mirror pi&ugrave; vicino a voi. Una volta ottenuto
il contenuto delle directory  <tt/common/ e <tt/elf/, si deve modificare
<tt>/usr/X11R6/lib/X11/config/linux.cf</tt> per cambiare le linee che dicono

<tscreen><verb>
#define LinuxElfDefault         NO
#define UseElfFormat            NO
</verb></tscreen>

in modo da dire <tt/YES/ invece. In caso contrario una costruzione di
xpm tenter&agrave; di fare le cose sbagliate con <tt/jumpas/ 
e le relative reliquie del passato

<item> <Bf/Mosaic/. Non ho certo il modo di ricostruirlo per conto mio,
ma il codice binario del Mosaic 2.7b1 disponibile dalla NCSA, &egrave; in ELF.
Tuttavia il link &egrave; stato eseguito con una versione errata di X, col
risultato che su sistemi normali si lamenter&agrave; di non trovare 
<tt/libXpm.so.4.5/. La correzione abbastanza semplice &egrave; di editarlo con
cura con Emacs o con un altro editor che gestisce correttamente i file
binari. Dopo aver trovato le occorrenze della stringa 
<tt/libXpm.so.4.5^@/ (dove <tt/^@/ &egrave; un carattere NUL --- ASCII zero ---),
cancellare <tt/.5/ e aggiungere due caratteri dopo il NUL per evitare
il cambiamento della lunghezza del file.

</itemize>

<sect1> Patch
<p>
<itemize>

<item> <bf>e2fsutils</bf>.  Le Utility per il Second Extended File
System hanno bisogno di un patch da <url
url="ftp://ftp.ibp.fr/pub/linux/ELF/patches/e2fsprogs-0.5b.elf.diff.gz">
per essere compilate correttamente come librerie condivise. Remy Card
dice ``Questo &egrave; il patch per l'ELF che probabilmente verr&agrave; incluso nella
prossima versione di e2fsck e compagnia bella.''

<item> <bf>file</bf>. Questo funziona in ogni caso, ma pu&ograve; essere 
migliorato: <url
url="http://sable.ox.ac.uk/~jo95004/patches/file.diff"> aggiunge il
supporto per identificare in file binari in ELF che hanno subito lo strip
e che sono `mixed-endian'.

<item> <bf>Il Kernel</bf>. Almeno dalla versione 1.3.8, lo sviluppo
della serie di kernel 1.3 hanno una opzione nel <tt/make config/
per permettere di costruirlo usando i tool dell'ELF.
Se si sta usando la serie 1.2, avete due possibilit&agrave;:

<enum>
<item> Si modifichi leggermente il Makefile per usare il compilatore
a.out. Basta cambiare le definizioni
<tt>CC</tt> e <tt>LD</tt> in modo che appaiano come

<tscreen><code>
LD      =ld -m i386linux
CC      =gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
</code></tscreen>

In alternativa,

<item> Si applichino i patch di H J Lu che permettono di compilare il 
kernel in ELF (e inoltre aggiungono la possibilit&egrave; di fare i core
dump in ELF).
</enum>

Lasciatemi ripetere che ne l'una ne l'altra sono necessarie se
si sta usando la serie 1.3 dei kernel.

<item><bf><tt>ps</tt> (procps-0.97)</bf> Il programma <tt/psupdate/
ha bisogno di un patch per lavorare se si &egrave; compilato il kernel in ELF.
Questo &egrave; disponibile in 
<url url="linux.nrao.edu:/pub/people/juphoff/procps">,
sia come patch a vanilla 0.97 e sia come intero file di tar. Una nuova
versione di procps dovrebbe essere distribuita presto con il patch
gi&agrave; a posto, cos&igrave; se si potr&agrave; trovare procps 0.98 nel momento in cui
leggerete questo, allora questo patch sar&agrave; probabilmente obsoleto.

</itemize>

<sect>Informazioni aggiuntive

<p> 
<itemize>

<item>La mailing list <tt>linux-gcc</tt> &egrave; davvero il miglior posto
per vedere cosa sta succedendo, di solito senza mai pubblicarci
qualcosa. Ricordate, questo non &egrave; Usenet, perci&ograve; tenete per voi
le vostre domande a meno che non stiate sviluppando.
Per istruzioni per ottenere questa mailing list, si mandi un messaggio
contenente la parola <tt>help</tt> a 
<tt>majordomo@vger.rutgers.edu</tt>. Gli archivi di questa mailing list sono a 
<url
url="http://homer.ncm.com/">.

<item> C'&egrave; un certo ammontare di informazioni riguardo quello che
la lista linux-gcc sta facendo alla mia <url
url="http://sable.ox.ac.uk/~jo95004/elf.html" name="pagina web sull'ELF">,
quando mi ricordo di aggiornarla. Questa ha anche un link all'ultima
versione di questo HOWTO, e i pacchetti a cui questo si riferisce.
Per le persone negli Stati Uniti, e per gli altri con collegamenti 
scarsi ai siti accademici della Gran Bretagna (cio&egrave; praticamente
chiunque fuori dall'ambiente accademico della Gran Bretagna),
questa pagina e' completamente replicata a
<url url="http://www.blackdown.org/elf/elf.html">

<item> Si veda anche la <url 
url="http://www.intac.com/~cully/elf.html" name="esperienza di upgrade ad ELF">
di Bobby Shmit

<item>La <url url="ftp://sunsite.unc.edu/pub/Linux/docs/faqs/GCC-FAQ.html"
name="GCC-FAQ"> contiene informazioni pi&ugrave; generali sullo sviluppo
e alcuni dettagli tecnici sull'ELF.

<item>Esiste anche la documentazione sul formato del file su <url
url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz"
name="tsx-11">. Questa pagina probabilmente sar&agrave; pi&ugrave; utile
alle persone che vogliono capire, fare il debug o riscrivere programmi
che si cimentano direttamente con oggetti binari.

<item>Il documento di H J Lu <url name="ELF: From The Programmer's
Perspective"
url="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.latex.tar.gz">
contiene informazioni molto utili e pi&ugrave; dettagliate sul programmare
con l'ELF. Se non si &egrave; in grado di gestire file in formato LaTeX,
&egrave; anche disponibile in PostScript

<item> Esiste una pagina del manuale (man page N.d.T.) <tt>dlopen(3)</tt> 
fornita con il pacchetto <tt>ld.so</tt>.

</itemize>

<sect> Legalese

<p> Tutti i trademark usati in questo documento sono riconosciuto
come appartenenti ai rispettivi prorietari. <em>(Scovate l'ironia a questo
punto...)</em>

<p> Il diritto di Daniel Barlow di essere identificato come l'autore di
questo lavoro, &egrave stato asserito in accordo alle sezioni 77 e 78 del
Copyright Designs and Patents Act 1988.  <em>(Prova per asserzione...
sembra di essere in Usenet)</em>

Questo documento &egrave; protetto dai diritti d'autore (C) 1995 Daniel Barlow
<tt/&lt;daniel.barlow@sjc.ox.ac.uk&gt;/ 
Il documento pu&ograve; essere riprodotto e distribuito in tutto o in parte,
in qualsiasi formato fisico o elettronico, a patto che questo avviso
di copyright sia mantenuto su tutte le copie. La redistribuzione commerciale
&egrave; permessa; tuttavia l'autore gradirebbe essere avvisato di qualunque
distribuzione.

Tutte le traduzioni, lavori derivati, o lavori aggregati che incorporano
qualunque documento Linux HOWTO deve essere coperto da questo avviso
di copyright. Questo sigifica che non si pu&ograve; produrre un lavoro derivato
da un HOWTO e imporre restrizioni addizionali sulla sua distribuzione.
Eccezioni a queste regole possono essere garantite sotto certe condizioni;
si prega di contattare il coordinatore degi Linux HOWTO all'indirizzo
fornito pi&ugrave; sotto.

In breve, vogliamo promuovere la disseminatione di questa informazione
attraverso tutti i canali possibili. Tuttavia, desideriamo mantenere il
copyright sui documenti HOWTO, e vorremmo essere avvisati di ogni piano
di distribuzione degli HOWTO.

Se si hanno domande, per favore contattare Greg Hankins, il coordinatore
dei Linux HOWTO a 
<tt/gregh@sunsite.unc.edu/ con la posta elettronica, oppure  al +1 404 853
9989.

</article>