<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
<TITLE>Il Linux ELF HOWTO: Installazione</TITLE>
<LINK HREF="ELF-HOWTO-3.html" REL=next>
<LINK HREF="ELF-HOWTO-1.html" REL=previous>
<LINK HREF="ELF-HOWTO.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="ELF-HOWTO-3.html">Avanti</A>
<A HREF="ELF-HOWTO-1.html">Indietro</A>
<A HREF="ELF-HOWTO.html#toc2">Indice</A>
<HR>
<H2><A NAME="s2">2.</A> <A HREF="ELF-HOWTO.html#toc2">Installazione</A></H2>
<H2><A NAME="ss2.1">2.1</A> <A HREF="ELF-HOWTO.html#toc2.1">Background</A>
</H2>
<P> Lo scopo di questa conversione è 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ò più di intelligenza nella ricerca delle librerie rispetto
al semplice `guarda in <CODE>/lib</CODE>, <CODE>/usr/lib</CODE> e in tutti i posti
in cui il programma è stato detto di cercare'.</P>
<P>La bestiola responsabile di ricercare le librerie in linux è
<CODE>/lib/ld.so</CODE>. 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 <CODE>ld.so</CODE>, e lasciano
che sia <CODE>ld.so</CODE> 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è a <CODE>ld.so</CODE> sia stato
detto di cercare nelle nuove directory. Questa è una funzionalità essenziale
per l'operazione di scambio delle directory che segue.</P>
<P>Ne consegue che, naturalmente, ogni tentativo di cancellare o spostare
<CODE>ld.so</CODE> causerà il fatto che <EM> ogni programma che sia linkato
dinamicamente sul sistema linux, cesserà di funzionare</EM>. Questa è
generalmente ritenuta una cattiva cosa...</P>
<P>Per il codice binario in ELF, viene fornito un dynamic loader (caricatore
dinamico del codice) alternativo. Si chiama <CODE>/lib/ld-linux.so.1</CODE>,
e fa esattamente le stesse cose di <CODE>ld.so</CODE>, ma per i programmi in ELF.
<CODE>ld-linux.so.1</CODE> usa gli stessi programmi e gli stessi file di supporto
(<CODE>ldd</CODE>, <CODE>ldconfig</CODE>, e <CODE>/etc/ld.so.conf</CODE>, che vengono usati
dal loader del formato a.out.</P>
<P>L'idea di base, poi, è che le cose che riguardano lo sviluppo in ELF
(compilatori, include files e librerie) vadano in
<CODE>/usr/{bin,lib,include}</CODE> dove attualmente si trovano quelle
che riguardano l'a.out, e che queste ultime vadano spostate in
<CODE>/usr/i486-linuxaout/{bin,lib,include}</CODE>.
<CODE>/etc/ld.so.conf</CODE> farà una lista di tutti i posti dove ci si
può aspettare di trovare una libreria, e <CODE>ldconfig</CODE> è abbastanza
intelligente da distinguere tra le varianti di ELF e di a.out.</P>
<P>Ci sono un paio di eccezioni al piazzamento delle librerie, tuttavia.</P>
<P>
<UL>
<LI> Alcuni vecchi programmi sono stati costruiti senza l'uso di
<CODE>ld.so</CODE>. Questi cesseranno di funzionare se le loro librerie saranno
spostate. In questo modo, <CODE>libc.so*</CODE> e <CODE>libm.so*</CODE> devono rimanere
dove stanno in <CODE>/lib</CODE>, 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), è meglio
lasciarle dove stanno, sebbene le più nuove (<CODE>libX*.so.6</CODE>) debbano essere
spostate. Lo spostamento delle vecchie librerie causerà un apparente
malfunzionamento dei programmi xview, mentre non spostare le nuove librerie,
causerà 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à citate, (se si sa quali programmi sono, si può
far girare ldd su di loro per capire di quali librerie abbiano
bisogno <EM>prima</EM> di rovinarli), allora si hanno essenzialmente due
possibilità. La prima è che si possono estrarre i file tar in una directory
temporanea, controllare se le proprie preziose librerie saranno sovrascritte,
e, se così fosse, si sposterà la versione in ELF della libreria in,
diciamo, <CODE>/usr/i486-linux/lib</CODE> invece che <CODE>/lib</CODE>.
Sia sia sicuri che il proprio <CODE>ld.so.conf</CODE> abbia
<CODE>/usr/i486-linux/lib</CODE>, e si faccia girare <CODE>ldconfig</CODE>
e non ci si pensi più. La seconda cosa è che si può ricompilare o acquisire una
copia più recente del programma che crea questa seccatura. Questa
non sarebbe affatto una cattiva idea, se possibile.
</LI>
<LI> Se si ha <CODE>/usr</CODE> e <CODE>/</CODE> su differenti partizioni,
sarà necessario muovere almeno alcune delle librerie in <CODE>/lib</CODE>
da qualche parte sul root disk, non in <CODE>/usr</CODE>. Si può sia
identificare i programmi necessari al system startup o quando si è in
modo single user (singolo utente), e trovare le librerie che usano, oppure
può dipendere dal vostro integratore del sistema o della distribuzione,
che può aver già fatto questo per voi, e semplicemente spostare tutte
(beh... alcune. Si veda quanto già detto per le eccezioni) le librerie
da <CODE>/lib</CODE> a <CODE>/lib-aout</CODE>.
</LI>
</UL>
</P>
<H2><A NAME="ss2.2">2.2</A> <A HREF="ELF-HOWTO.html#toc2.2">Prima di partire --- Note e diffide</A>
</H2>
<P>
<UL>
<LI> E` necessario che sul proprio sistema giri un kernel posteriore
alla versione 1.1.52 <B>con il supporto per il formato binario ELF</B>.
</LI>
<LI> E` molto raccomandabile preparare o procurarsi dei dischi di
root/boot, ad esempio come quelli di Slackware. Probabilmente non se ne
avrà 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 è meglio
che curare', possono essere d'aiuto per ogni situazione scomoda in cui
si può finire, delle copie linkate staticamente di <CODE>mv</CODE>, <CODE>ln</CODE>, 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à intrinseche della shell), per ogni situazione scomoda
in cui si può finire.
</LI>
<LI> Se avete seguito lo sviluppo dell'ELF, potete avere le librerie
ELF in <CODE>/lib/elf</CODE> (tipicamente <CODE>libc.so.4</CODE> e compagnia varia).
Le applicazioni costruite in questa maniera devono essere ricostruite,
e poi la directory rimossa. Non è necessario avere una directory
<CODE>/lib/elf</CODE>!
</LI>
<LI> 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
<CODE>/sbin/</CODE><EM>qualcosa</EM> e non si ha una directory <CODE>/sbin</CODE>,
propabilmente si troveranno i programmi relativi in
<CODE>/bin</CODE> o in <CODE>/etc/</CODE>.
</LI>
</UL>
</P>
<H2><A NAME="ss2.3">2.3</A> <A HREF="ELF-HOWTO.html#toc2.3">Si avrà bisogno di...</A>
</H2>
<P> I seguenti pacchetti sono disponibili a
<A HREF="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/">ftp://tsx-11.mit.edu/pub/linux/packages/GCC/</A> e a
<A HREF="ftp://sunsite.unc.edu/pub/Linux/GCC/">ftp://sunsite.unc.edu/pub/Linux/GCC/</A>. Entrambe i siti sono
ampiamente distribuiti in giro per il mondo; per favore, prendetevi il tempo
necessario per cercare il sito più vicino a voi. E` più veloce per voi
e per chiunque altro.</P>
<P>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 <CODE>release.</CODE><EM>packagename</EM>.
Questo specialmente se si scaricano versioni più recenti di quelle
descritte qui, poichè la procedura può essere cambiata.</P>
<P>
<UL>
<LI> <CODE>ld.so-1.7.3.tar.gz</CODE> --- il nuovo linker dinamico
</LI>
<LI> <CODE>libc-5.0.9.bin.tar.gz</CODE> --- le immagini ELF condivise per
la libreria C e i suoi amici (<CODE>m</CODE> (maths), <CODE>termcap</CODE>, <CODE>gdbm</CODE>, e
così via), più 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 è 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.
</LI>
<LI> <CODE>gcc-2.7.0.bin.tar.gz</CODE> --- il compilatore C in ELF. Include
anche un compilatore C in a.out che capisce il nuovo ormato delle directory.
</LI>
<LI> <CODE>binutils-2.5.2l.17.bin.tar.gz</CODE> --- le utility binarie della GNU
per Linux. questi sono programmi come <CODE>gas</CODE>, <CODE>ld</CODE>, <CODE>strings</CODE> e così
via, la maggior parte dei quali sono richiesti per far funzionare il
compilatore C.
</LI>
</UL>
</P>
<H2><A NAME="ss2.4">2.4</A> <A HREF="ELF-HOWTO.html#toc2.4">Ridisponendo il proprio filesystem</A>
</H2>
<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à smanettato con l'ELF --- quelli che ci si aspetta abbiano
già la capacità di adattare le cose in modo appropriato. Andiamo!</P>
<P>
<OL>
<LI> Creare le nuove directory verso cui si sposteranno le cose di a.out
<BLOCKQUOTE><CODE>
<HR>
<PRE>
mkdir -p /usr/i486-linuxaout/bin
mkdir -p /usr/i486-linuxaout/include
mkdir -p /usr/i486-linuxaout/lib
mkdir /lib-aout
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</LI>
<LI> Si scompatti il pacchetto del linker dinamico <CODE>ld.so-1.7.3</CODE>
nella directory in cui di solito si mette il codice sorgente, poi si legga
lo script <CODE>ld.so-1.7.3/instldso.sh</CODE> appena estratto.
Se si ha un sistema realmente standard, è sufficiente farlo girare
digitando <CODE>sh instldso.sh</CODE>, ma se si ha qualcosa di insolito
allora si faccia l'installazione a mano. `Qualcosa di insolito' comprende
<UL>
<LI> usare zsh come shell (alcune versioni di zsh definiscono
<CODE>$VERSION</CODE>, il che sembra confondere <CODE>instldso.sh</CODE>)
</LI>
<LI> avere link simbolici da <CODE>/lib/elf</CODE> a <CODE>/lib</CODE>
(il che non è ncessario, ma si possono aver avuto delle valide ragioni per
farlo se si è seguito lo sviluppo dell'ELF).
</LI>
</UL>
</LI>
<LI> Si editi <CODE>/etc/ld.so.conf</CODE> per aggiungere le nuove directory
<CODE>/usr/i486-linuxaout/lib</CODE> (e <CODE>/lib-aout</CODE> se si pensa di averne
bisogno). Poi si faccia girare <CODE>/sbin/ldconfig -v</CODE> per controllare
che sono state caricate le nuove directory.
</LI>
<LI> Si muovano tutte le librerie a.out da <CODE>/usr/*/lib</CODE> a
<CODE>/usr/i486-linuxaout/lib</CODE>. Si noti che ho scritto `librerie'
non `qualunque cosa'. Quindi si intende i file che rispondono al nome
di <CODE>lib*.so*</CODE> , <CODE>lib*.sa*</CODE>, o <CODE>lib*.a</CODE>. Non si incominci a
spostare <CODE>/usr/lib/gcc-lib</CODE> o niente di sciocco come questo in
giro.
</LI>
<LI> Adesso si guardi a <CODE>/lib</CODE>. Si lasci intatto <CODE>libc.so*</CODE>,
<CODE>libm.so*</CODE>, e <CODE>libdl.so*</CODE>. Se si hano link simbolici a librerie X
(<CODE>libX*.so.3*</CODE>) lasciate li anche questi --- XView e qualche altro
pacchetto potrebbe averne bisogno. Si lasci <CODE>ld.so*</CODE>, <CODE>ld-linux.so*</CODE>
e qualunque altro file che comincia con <CODE>ld</CODE>. Per le librerie rimanenti,
(se ne avete qualcuna): se si ha <CODE>/usr</CODE> sulla partizione root,
si mettano in <CODE>/usr/i486-linuxaout/lib</CODE>. Se si ha <CODE>/usr</CODE>
montata separatamente, si mettano in <CODE>/lib-aout</CODE>. Adesso si
faccia girare <CODE>ldconfig -v</CODE>
</LI>
<LI> Si rimuova la directory <CODE>/usr/lib/ldscripts</CODE> se è li,
per la preparazione all'installazione delle utility binarie (che
la ricreeranno).
</LI>
<LI> Si rimuova qualsiasi copia di <CODE>ld</CODE> e di <CODE>as</CODE>
(<EM>eccetto</EM> <CODE>ld86</CODE> e <CODE>as86</CODE>) che si può trovare in
<CODE>/usr/bin</CODE>.
</LI>
<LI> Alcune versioni del GNU tar sembrano avere problemi riguardo
ai link simbolici nella directory di destinazione. Si hanno due possibilità
a questo punto:
<OL>
<LI> (perferibilmente) Si usi <CODE>cpio</CODE> invece di <CODE>tar</CODE>, poichè non
ha questo problema. <CODE>zcat /ovunque/sia/stato/messo/libc-5.0.9.tar.gz | cpio
-iv</CODE> è l'incantesimo magico qui, che deve essere eseguito dalla
directory root.
</LI>
<LI> (se non si ha installato cpio) Prima di installare le immagini
della libc, si può andare in <CODE>/usr/include</CODE> e rimuovere alcune
parti.
Questa è brutta. Molti pacchetti (come ncurses) sono installati
in <CODE>/usr/include</CODE> dai manutentori della distribuzione e <EM>non</EM>
sono fornite con la libreria C. Si faccia un backup dell'albero della
directory <CODE>/usr/include</CODE>, si usi <CODE>tar tzf</CODE> per vedere
cosa c'è nell'archivio prima di scompattarlo, poi cancellare le poche cose
di <CODE>/usr/include</CODE> che sono al momento contenute. Poi si
scompatti il file <CODE>libc-5.0.9.bin.tar.gz </CODE> dalla directory root.
</LI>
</OL>
</LI>
<LI> installare il pacchettocon le utility binarie. <CODE>tar -xvzf binutils-2.5.2.l17.bin.tar.gz -C / </CODE> è una buona maniera per farlo.
</LI>
<LI> A questo punto è stato installato tutto quello che serve per
far girare gli eseguibili in ELF. Gli esperti medici raccomandano che
i lavoratori VDU (VDU è 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,
è possibile che non si sia in grado di compilare programmi in formato a.out,
fino a che non si installa il nuovo gcc.
</LI>
<LI> fare il backup e cancellare tutto in <CODE>/usr/lib/gcc-lib/{i486-linux, i486-linuxelf, i486-linuxaout}/ </CODE> Se
si usa un driver <CODE>gcc</CODE> 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.
</LI>
<LI> Alcuni programmi (solitamente vari programmi per X) usano
<CODE>/lib/cpp</CODE>, che generalmente sotto linux è un link a
<CODE>/usr/lib/gcc-lib/i486-linux/</CODE><EM>version</EM><CODE>/cpp</CODE>. Siccome
ilpasso precedente ha cancellato qualsiasi versione a cui <CODE>cpp</CODE>
stava puntando, bisognerà ricreare il link:
<BLOCKQUOTE><CODE>
<PRE>
$ cd /lib
$ ln -s /usr/lib/gcc-lib/i486-linux/2.7.0/cpp .
</PRE>
</CODE></BLOCKQUOTE>
</LI>
<LI> La gente di FSSTND hanno ancora una volta giustificato la loro
esistenza muovendo i file <CODE>utmp</CODE> e <CODE>wtmp</CODE> da <CODE>/var/adm</CODE>
a <CODE>/var/run</CODE> e a <CODE>/var/log</CODE> rispettivamente. Bisognerà
aggiungere alcuni link che dipendono da dove attualmente questi risiedono,
e può essere necessario creare le directory
<CODE>/var/log</CODE> and <CODE>/var/adm</CODE>. Io ho riprodotto qui sotto
l'output del comando <CODE>ls -l</CODE> delle parti appropriate del mio sistema:
<BLOCKQUOTE><CODE>
<PRE>
$ 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
</PRE>
</CODE></BLOCKQUOTE>
Si controlli il FSSTND (dagli archivi LDP come
<A HREF="ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/">ftp://sunsite.unc.edu/pub/Linux/docs/fsstnd/</A>) per la storia completa.
</LI>
<LI> Questo passo è opzionale. Se si ha intenzione di continuare a
compilare programmi in formato a.out, questo è il momento ideale per
installare libc.so 4.7 <EM>x</EM>. Lo si scompatti dalla directory root,
poichè a questo punto si è senz'altro in grado di farlo senza
ulteriori spiegazioni.
</LI>
</OL>
</P>
<P><B> Fatto! </B> Semplici test che si possono provare sono: </P>
<P>
<BLOCKQUOTE><CODE>
<HR>
<PRE>
$ 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
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</P>
<P>seguiti ovviamente dal tradizionale programma ``Hello World''. Si provi
con <CODE>gcc</CODE> e con <CODE>gcc -b i486-linuxaout</CODE> per verificare che
sia il compilatore ELF, sia il compilatore a.out sono configurati
correttamente.</P>
<H2><A NAME="ss2.5">2.5</A> <A HREF="ELF-HOWTO.html#toc2.5">Come dovrebbe sembrare (schema della struttura delle directory)</A>
</H2>
<P> Questa è una guida deliberatamente vaga a che cosa sono i files
che avete appena installato. Può essere utile per la soluzione di problemi,
o per decidere cosa cancellare.</P>
<H3><CODE> /lib </CODE></H3>
<P>
<UL>
<LI> Linker dinamici <CODE>ld.so</CODE> (a.out) e <CODE>ld-linux.so.1</CODE> (ELF).
Entrambe possono essere link simbolici, ma siate sicuri che i file
a cui puntano esistano.
</LI>
<LI> Librerie condivise di base <CODE>libc.so.4</CODE>, <CODE>libm.so.4</CODE> (a.out)
Questi sono link simbolici, ma curate che anche questi puntino a file
esistenti.
</LI>
<LI> Librerie condivise di base <CODE>libc.so.5</CODE>, <CODE>libm.so.5</CODE>,
<CODE>libdl.so.1</CODE>, <CODE>libcurses.so.1</CODE>, <CODE>libtermcap.so.2</CODE>, (ELF).
Anche questi sono link simbolici.
</LI>
<LI> <EM>Un mucchio</EM> di link simbolici. Per ciascuna libreria, dovrebbe
esserci un file attuale (per esempio <CODE>libc.so.5.0.9</CODE>), un link simbolico
che punta allo stesso con solo il major number della versione (<CODE>libc.so.5</CODE>)
ed un link simbolico che punta a quest'ultimo senza numero di versione
(<CODE>libc.so</CODE>). In questa maniera:
<BLOCKQUOTE><CODE>
<HR>
<PRE>
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
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</LI>
</UL>
</P>
<H3><CODE>/usr/lib</CODE></H3>
<P>
<UL>
<LI> Tutti i file che non sono librerie e che esistevano già in precedenza.
</LI>
<LI> <CODE>libbfd.so*</CODE>,<CODE>libdb.so*</CODE>, <CODE>libgdbm.so*</CODE>, le librerie
condivise di ELF. Tutte consistono di tre file come spiegato in precedenza
nella sezione <CODE>/lib</CODE>.
</LI>
<LI><CODE>libbsd.a</CODE>, <CODE>libgmon.a</CODE>, <CODE>libldso.a</CODE>, <CODE>libmcheck.a</CODE>,
<CODE>libieee.a</CODE>, <CODE>libmcheck.a</CODE> ed un <CODE>lib*.a</CODE> 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ò usare lo switch <CODE>gcc -g</CODE> con le
librerie condivise, così non ha più molto senso fare compilazioni statiche.
</LI>
<LI> <CODE>crt0.o</CODE>, <CODE>gcrt0.o</CODE>. a.out, che sono i file di `inizio di
programma';uno di questi è linkato come primo file in ogni programma
di tipo a.out, a meno che non si prendano degli accorgimentio per evitarlo.
</LI>
<LI> <CODE>crt1.o</CODE>, <CODE>crtbegin.o</CODE>, <CODE>crtbeginS.o</CODE>, <CODE>crtend.o</CODE>,
<CODE>crtendS.o</CODE>, <CODE>crti.o</CODE>, <CODE>crtn.o</CODE>, <CODE>gcrt1.o</CODE>. I file di startup
dell'ELF. Questi fanno una cosa simile a quanto appena visto per i
file <CODE>*crt0.o</CODE>
</LI>
</UL>
</P>
<H3><CODE> /usr/lib/ldscripts </CODE></H3>
<P>
<UL>
<LI> Questo è dove risiede lo script driver per <CODE>ld</CODE>, come suggerisce
il nome stesso. Dovrebbe apparire come
<BLOCKQUOTE><CODE>
<HR>
<PRE>
$ 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
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</LI>
</UL>
</P>
<H3><CODE>/usr/i486-linux/bin</CODE></H3>
<P>
<UL>
<LI> <CODE>ar</CODE>, <CODE>as</CODE>, <CODE>gasp</CODE>, <CODE>ld</CODE>, <CODE>nm</CODE>, <CODE>ranlib</CODE>,
<CODE>strip</CODE>. Questi attualmente sono tutti link simbolici alle utility
binarie in <CODE>/usr/bin</CODE></LI>
</UL>
</P>
<H3><CODE>/usr/i486-linuxaout/bin</CODE></H3>
<P>
<UL>
<LI> <CODE>as</CODE> --- L'assembler per l'a.out, e <CODE>gasp</CODE>, il suo preprocesore
delle macro
</LI>
<LI> <CODE>ar</CODE>, <CODE>ld</CODE>, <CODE>nm</CODE>, <CODE>ranlib</CODE>, <CODE>strip</CODE> --- link simbolici
alle utility binarie in <CODE>/usr/bin</CODE>
</LI>
</UL>
</P>
<H3><CODE>/usr/i486-linux/lib</CODE></H3>
<P>
<UL>
<LI> <CODE>ldscripts</CODE> è un link simbolico a <CODE>/usr/lib/ldscripts</CODE>.</LI>
</UL>
</P>
<H3><CODE>/usr/i486-linuxaout/lib</CODE></H3>
<P>
<UL>
<LI> <CODE>lib*.so*</CODE>. librerie condivise per a.out. Sono necesarie per
far girare programmi in formato a.out.
</LI>
<LI> <CODE>lib*.sa</CODE>. mozziconi di librerie per il formato a.out.
Necessarie per compilare programmi a.out. Se non si intende farlo,
si possono tranquillamente rimuoverle.
</LI>
<LI> <CODE>lib*.a</CODE>. librerie statiche per il formato a.out. Necessarie
per compilare programmi statici in a.out (ciaoè quando si compila con
<CODE>-g</CODE>). Di nuovo, si possono rimuovere se non si ha questa intenzione.
</LI>
<LI> <CODE>ldscripts</CODE> è un link simbilico a <CODE>/usr/lib/ldscripts</CODE></LI>
</UL>
</P>
<H3><CODE>/usr/lib/gcc-lib/i486-linux/2.7.0</CODE></H3>
<P>
<UL>
<LI> Questa directory contiene una versione di gcc 2.7.0 predisposta
per compilare programmi in ELF.</LI>
</UL>
</P>
<H3><CODE>/usr/lib/gcc-lib/i486-linuxaout/2.7.0</CODE></H3>
<P>
<UL>
<LI> 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ò cancellare questa directory. liberando in questo modo 4Mb.</LI>
</UL>
</P>
<H2><A NAME="ss2.6">2.6</A> <A HREF="ELF-HOWTO.html#toc2.6">Errori comuni (Niente Panico!)</A>
</H2>
<P> ... in grandi lettere amichevoli.</P>
<P>
<DL>
<DT><B> Avete spostato le cose sbagliate e non funziona nulla.</B><DD><P>Avete ancora una shell in grado di girare, tuttavia, e con un pò di ingenuità
potete fare un sacco di cose con le caratteristiche intrinseche della shell.
Ricordate che <CODE>echo *</CODE> è un sostituto accettabile per <CODE>ls</CODE>,
e che <CODE>echo >>filename</CODE> può essere usato per aggiungere linee
ad un file. Inoltre non dimenticate che <CODE>ldconfig</CODE> è linkato staticamente.
Se avete spostato, ad esempio, <CODE>libc.so.4</CODE> in <CODE>/lib-aout</CODE>
erroneamente, potete fare <CODE>echo "lib-aout"
>>/etc/ld.so.conf ; ldconfig -v</CODE> ed essere di nuovo a posto.
se avete spostato <CODE>/lib/ld.so</CODE> potete essere capaci di
fare <CODE>sln /stupido/posto/ld.so /lib/ld.so</CODE>, se avete una copia
di ln linkata staticamente, e probabilmente vi ritroverete con tutto
a posto.</P>
<DT><B><CODE> no such file or directory: /usr/bin/gcc </CODE></B><DD><P>... quando sapete che <EM>esiste</EM> quel file. Questo solitamente
significa che il loader dinamico dell'ELF <CODE>/lib/ld-linux.so.1</CODE>
non è installato, o non è leggibile per qualche motivo. Dovreste
averlo installato al passo 2 in precedenza.</P>
<DT><B><CODE> not a ZMAGIC file, skipping </CODE></B><DD><P>dal comando <CODE>ldconfig</CODE>. Questo è perchè avete una vecchia versione
del pacchetto ld.so, così dovete prenderne una nuova. Riguardate il passo
2dell'installazione.</P>
<DT><B><CODE> bad address </CODE></B><DD><P>tentando di far girare qualunque cosa in ELF. State usando il kernel
1.3.<EM>x</EM>, dove <EM>x</EM><3. Fate un upgrade alla versione 1.3.3
oppure fate un downgrade a qualche versione 1.2.<EM>x</EM></P>
<DT><B><CODE> _setutent: Can't open utmp file </CODE></B><DD><P>Questo messaggio è 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.</P>
<DT><B><CODE> gcc: installation problem, cannot exec <EM>qualcosa</EM>: No such file or directory</CODE></B><DD><P>Quando si tenta di fare una compilazione in a.out (<EM>qualcosa</EM> in
genere sono <CODE>cpp</CODE> o <CODE>cc1</CODE>). Può essere sia una cosa corretta,
oppure verosimilmente avete digitato</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ gcc -b -i486-linuxaout
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>quando avreste dovuto digitare</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ gcc -b i486-linuxaout
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Notate che `i486' <EM>non</EM> inizia con un meno.</P>
</DL>
</P>
<HR>
<A HREF="ELF-HOWTO-3.html">Avanti</A>
<A HREF="ELF-HOWTO-1.html">Indietro</A>
<A HREF="ELF-HOWTO.html#toc2">Indice</A>
</BODY>
</HTML>
distrib
>
Mandriva
>
2008.1
>
x86_64
>
media
>
main-release
>
by-pkgid
>
e05c4514608e650af9b28d9be1d35a18
>
files
>
360
