ELF (Executable and Linking Format) est un format de données binaires originellement développé par USL (UNIX System Laboratories) et désormais utilisé dans Solaris et dans le Système 5 Version 4. De par sa flexibilité accrue par rapport à l'ancien format a.out que Linux utilisait précédemment, les développeurs de GCC et de librairies décidèrent l'an dernier de se mettre à ELF et d'ainsi modifier le format standard des fichiers binaires de Linux.
Cette flexibilité accrue a en fait deux intérêts essentiels pour le programmeur d'applications moyen :
-fPIC et d'ensuite établir les liens avec une commande telle que :
gcc -shared -Wl,-soname,libfoo.so.y -o libfoo.so.y.x *.o
Cependant, il faut prendre en compte qu'ELF est peut-être un peu moins rapide. Les chiffres les plus couramment cités font état d'une baisse de performance de 1 à 5%, bien que les tests effectués jusqu'à présent indiquent que la différence est suffisamment faible pour se perdre dans le bruit dû autres événements qui arrivent au même moment. Si vous avez un visualiseur ou un moyen d'imprimer des fichiers TeX ou PostScript, vous pourrez lire speed.comp-1.0.tar.gz qui se trouve quelque part sur SunSite.
Le ralentissement vient du fait que les codes des librairies ELF doivent être indépendants de la position (c'est ce que signifie le commutateur -fPIC vu ci-dessus signifie) : un registre doit alors être dédié pour la conservation des offsets. C'est un de moins pour les variables, alors que les 80x86 ont déjà une pénurie de registres à usage général. Notez bien que les différences de vitesse ne s'appliquent qu'aux parties du code qui font partie des librairies partagées. Pour les applications ou le noyau, il n'y a aucune différence de vitesse entre a.out et ELF.
Il y a bon nombre d'erreurs de commises quant à ce que ELF va apporter à votre système :
Bien que ce soit le même conteneur binaire que celui que les systèmes SVR4 utilisent, cela n'implique pas que les programmes SVR4 vont soudainement se mettre à fonctionner sous Linux. Il en va de même que pour un format de disque - vous pouvez conserver des programmes Linux sur des disques au format MSDOS ou Minix, et vice versa, mais cela ne signifie pas pour autant que ces systèmes seront alors en mesure d'exécuter les programmes des autres.
Il est possible d'exécuter une application prévue pour une autre implémentation d'Unix pour des systèmes x86 sous Linux (cela dépend de l'application) mais suivre les instructions de ce HOWTO n'aura pas cet effet-là. Commencez par essayer le module iBCS du noyau (quelque part sur tsx-11.mit.edu) et voyez s'il ne satisfait pas vos besoins.
Vous pouvez très bien vous retrouver avec des fichiers exécutables plus petits compte tenu du fait que vous pouvez plus aisément créer des librairies partagées de code commun à de nombreux programmes. En général, si vous utilisez les mêmes options de compilation et que vous obtenez des exécutables plus petits qu'avec a.out, ce sera dû soit à un coup de chance soit à une version différente du compilateur. Pour ce qui est de la mention plus rapide, j'en serais surpris. Des augmentations de performances peuvent apparaître si vos fichier compilés sont plus petits, du fait de la baisse des transferts avec des fichiers d'échange ou des domaines fonctionnels plus grands qui rentrent dans le cache.
A la fin des procédures indiquées ci-après, vous aurez un système capable de compiler et d'exécuter à la fois des programmes a.out et ELF. Les nouveaux programmes seront compilés par défaut en ELF bien que cela puisse être modifié par l'intermédiaire d'un commutateur sur la ligne de commande. Il est communément admis qu'on encourt une perte de mémoire quand on dispose d'un système à la fois a.out et ELF : ainsi, si vous avez les deux sortes de programmes qui tournent en même temps, il va s'en suivre deux copies de la même librairie C en mémoire et ainsi de suite. Cela dit, il semblerait que cette différence de vitesse est imperceptible en utilisation normale sur un système avec 8Mo (je n'en ai en tout cas pas remarqué avec 8Mo). Vous perdez bien plus de mémoire chaque jour quand vous utilisez des programmes gourmands comme Emacs! ! ! ou les exécutables statiques de Mosaic ou de Netscape :-).
Du moins pas dans ce contexte.
Il y a essentiellement deux raisons pour mettre à jour votre système pour ELF, la première étant la flexibilité accrue décrite plus haut pour la programmation et la seconde étant que, au vu de la première, tout le monde le fera (ou l'a déjà fait). Les dernières versions de la librairie C et de GCC sont compilées seulement pour ELF et les autres développeurs se mettent également à ELF.
Beaucoup de personnes ont pour souci la stabilité (ce qui est légitime bien que terre-à-terre). ELF a été utilisé sous Linux depuis Août 1994 et a été publiquement disponible aux alentours de Mai ou Juin 1995 ; les problèmes les plus graves ne sont plus qu'un lointain souvenir. Vous devriez permettre quelques menus défauts -- comme avec toute mise à jour d'importance - mais la technologie à laquelle vous allez adhérer n'est plus experimentale. Pour un système sur lequel on fait un tant soit peu de développement ou sur lequel vous avez l'intention d'exécuter les programmes précompilés d'autres personnes, ELF est presque devenu une nécessité. Pensez à vous y mettre quand vous ferez la mise à jour pour le noyau 2.0.
Au moment où ce HOWTO fut originellement écrit, il n'y avait qu'une seule manière : celle décrite ci-dessous. De nos jours, il y a des distributions de haute qualité faciles à mettre à jour -- à moins que vous n'ayez investi un temps certain à peaufiner la configuration de votre machine, vous trouverez certainement que faire une sauvegarde de vos données personnelles et réinstaller à partir d'une distribution RedHat ou Debian est plus facile que de jouer avec les librairies et les compilateurs décrits ici.
Je me dois d'insister. L'installation décrite ici est un travail de plutôt faible envergure en elle-même (elle peut être faite en moins d'une heure, mis à part le temps de téléchargement des logiciels) mais elle peut donner lieu à de multiples erreurs qui risquent de vous laisser avec un système non bootable. Si vous ne vous sentez pas sûr de vous dans la mise à jour des librairies partagées, si les commandes ldconfig et ldd ne vous disent rien et si construire des paquetages à partir du code source ne vous enchante pas, vous devriez considérer la solution de facilité. Même si la description ne vous correspond pas, pensez y tout de même : si vous voulez un système totalement ELF, quelqu'un va devoir en compiler tous les exécutables.
Vous êtes toujours là ?