1. Cosa è l'ELF? Un introduzione

L'ELF (Executable and Linking Format) è 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à 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à' si manifesta essenzialmente in due benefici per il programmatore medio di applicazioni:

• E` molto più semplice creare librerie condivise con l'ELF. Usualmente, basta compilare tutti i file oggetto con -fPIC, e poi fare il link con un comando come

   gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o 
  

  Se questo sembra complicato, ovviamente è perchè 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 è descritto in un documento lungo 20 pagine --- vedere a ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.16.tar.gz per i dettagli).
• Il caricamento dinamico (dynamic loading, cioè il meccanismo usato dai programmi che possono caricare vari moduli durante l'esecuzione) è molto più semplice. Questo è 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ò essere compilato separatamente e il link può essere fatto mentre l'eseguibile gira, senza dover far fermare e ripartire il programma.

Detto questo, bisogna tener presente che l'ELF può essere un pò più 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 è 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ò leggere speed.comp-1.0.tar.gz, che è disponibile da qualche parte in SunSite. (?)

Il rallentamento deriva dal fatto che il codice delle librerie ELF deve essere indipendente dalla posizione (questo è quello che -fPIC stà ad indicare) e così 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è.

1.1 Che cosa ELF non è

Esiste un certo numero di fraintendimenti riguardo a cosa l'ELF farà per il proprio sistema:

Non è 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 è 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 è possibile eseguire applicazioni per altri unix per processori x86 sotto Linux, ma seguendo le istruzioni contenute in questo HOWTO non non si avrà questo effetto. Per questa esigenza, si provi a guardare il modulo per il kernel iBCS (da qualche parte su tsx-11.mit.edu) e si veda se questo coincide con le proprie esigenze.

Non è intrinsecamente più piccolo o più veloce

Si può anche finire per avere dei binari più piccoli tuttavia, poichè si possono creare più 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ù piccolo rispetto a quanto avveniva con il sistema a.out, è più verosimile che sia un caso fortunato, oppure a causa di una versione del compilatore differente. Per quanto riguarda la velocità, ne sarei veramente sorpreso. Gli incrementi di velocità potrebbero verificarsi se il proprio codice binario risultasse più piccolo, a causa di un minor swapping, o di aree funzionali più grandi che riuscirebbero ad essere contenute nella cache.

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

Alla fine della procedura qui descritta, si avrà 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à 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ì via. Dalle informazioni che ho avuto, la differenza di velocità non è percettibile nell'uso normale su di un sistema con 6Mb, (io certamente non ne ho notata in 8 Mb), così difficilmente è un problema seccante. Si perde molta più memoria ogni giorno, facendo girare programmi sovrabbondanti come Emacs, e programmi statici come Mosaic/Netscape :-)

Non ha nulla a che fare con Tolkien

O, almeno, non in questo contesto.

1.2 Perchè (non) ci si dovrebbe convertire a ELF

Ci sono essenzialmente due motivi per fare l'upgrade del proprio sistema per poter compilare ed eseguire il codice binario in ELF: il primo è la migliore flessibilità già spiegata, e il secondo è 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 è 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è Linus stesso si sarà covertito, per esempio.

La seconda è che sebbene la procedura di installazione descritta qui sia un piccolo lavoro di per se stesso, (può 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ù capace di eseguire il bootstrap. Se non ci si sente a proprio agio con l'eseguire l'upgrade delle librerie condivise, e i comandi ldconfig e ldd non significano nulla per chi legge, si può 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 è usato per applicazioni critiche), si può voler continuare comunque, per imparare cose nuove.

Siete ancora con noi?