<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE>Building and Installing Software Packages for Linux: Compatibilità all'indietro con i binari a.out</TITLE> <LINK HREF="Software-Building-HOWTO-7.html" REL=next> <LINK HREF="Software-Building-HOWTO-5.html" REL=previous> <LINK HREF="Software-Building-HOWTO.html#toc6" REL=contents> </HEAD> <BODY> <A HREF="Software-Building-HOWTO-7.html">Avanti</A> <A HREF="Software-Building-HOWTO-5.html">Indietro</A> <A HREF="Software-Building-HOWTO.html#toc6">Indice</A> <HR> <H2><A NAME="s6">6. Compatibilità all'indietro con i binari a.out</A></H2> <P> <P>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. <P>Come succede, le installazioni ELF hanno quasi sempre un completo insieme di librerie a.out nella directory <CODE>/usr/i486-linuxaout/lib</CODE>. 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. <P>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 <CODE>xcompat</CODE> di Debian, per eseguire applicazioni X a.out. <P> <H2><A NAME="ss6.1">6.1 Un esempio</A> </H2> <P> <P>Jerry Smith ha scritto il comodissimo programma <EM>xrolodex</EM> 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 <EM>lesstif</EM>. Ancor più sfortunatamente, il binario a.out su di un sistema ELF va in bomba con il seguente messaggio d'errore. <BLOCKQUOTE><CODE> <PRE> xrolodex: can't load library '//lib/libX11.so.3' No such library </PRE> </CODE></BLOCKQUOTE> (Traducendo: non è possibile caricare la libreria //lib/libX11.so.3; non c'è nessuna libreria con quel nome) <P>Si dà il caso che ci sia una tale libreria, in <CODE>/usr/i486-linuxaout/lib</CODE>, ma xrolodex è incapace di trovarla in fase di esecuzione. La soluzione semplice è di fornire un link simbolico nella directory <CODE>/lib</CODE>: <P><CODE>ln -s /usr/i486-linuxaout/lib/X11.so.3.1.0 libX11.so.3</CODE> <P> <P>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. <P>Dopo aver creato i tre link, <EM>xrolodex</EM> funziona bene. <P>Il pacchetto <EM>xrolodex</EM> era originariamente pubblicato su <A HREF="http://www.spectro.com/">Spectro</A>, ma sembra che sia sparito da lì. Attualmente può essere scaricato da <A HREF="http://metalab.unc.edu/pub/Linux/apps/reminder/xrolodex.tar.z">Sunsite</A> come file sorgente [512k] in formato <EM>tar.Z</EM>. <P> <P> <P> <HR> <A HREF="Software-Building-HOWTO-7.html">Avanti</A> <A HREF="Software-Building-HOWTO-5.html">Indietro</A> <A HREF="Software-Building-HOWTO.html#toc6">Indice</A> </BODY> </HTML>
