12.2. Pourquoi utiliser (qu'est-ce) a.out et les formats exécutables ELF ?
Précédent | Chapitre 12. Questions diverses. **Mise à jour en cours** | Suivant

## 12.2. Pourquoi utiliser (qu'est-ce) a.out et les formats exécutables ELF ?

Afin de comprendre pourquoi FreeBSD utilise le format a.out, vous devez d'abord savoir quelques trucs sur les 3 formats exécutables courant "dominants" pour UNIX :

- a.out Le vieux et `classique' format des objets unix. Il utilise un court et compact en-tête avec un nombre magique au début, qui est souvent utilisé pour caractériser le format (voir a.out(5) pour plus de détails). Il contient trois segments chargés : .text, .data, et .bss plus une table de symboles et une table de chaînes.

- COFF Le formats des objets SVR3. L'en-tête comprend une table de section, de telle sorte que vous avez plus de sections que juste .text, .data, et .bss.

- ELF Le successeur de COFF, qui permet des sections multiples et des valeurs possibles de 32 bits et 64 bits. Un inconvénient majeur : ELF a aussi été conçu en supposant le fait qu'il y qu'un seul ABI par architecture système. Cette hypothèse est assez incorrecte, et même dans le monde SYSV (qui a au moins 2 ABIs : SVR4, Solaris, SCO) cela ne se vérifie pas.

  FreeBSD essaye de contourner ce problème en fournissant un utilitaire pour marquer un exécutable connu ELF avec des informations sur l'ABI qui va avec. Regardez la page de manuel pour brandelf pour plus d'informations.

FreeBSD vient du camp "classique" et utilise traditionnellement le format a.out, une technologie esssayée et éprouvée à travers des générations de releases BSD. Bien qu'il a aussi été quelques fois possible de construire et de lancer des binaires natifs ELF (et noyau) sur un système FreeBSD, FreeBSD a initiallement résisté à la "pression" de passer à ELF comme format par défaut. Pourquoi ? Bien, quand le camp Linux ont fait leur difficile transition vers ELF, il ne suffisait pas de fuir le format exécutable a.out. mais leur mécanisme de librairies partagées basé sur des table de sauts inflexible ce qui rendait la construction de librairies partagées difficiles pour les vendeurs et développeurs. Depuis comme les outils ELF offrent une solution au problème des librairies partagées et semblent en général perçus comme "la voie du progrès" de toute façon, le coût de migration a été entendu comme nécessaire, et la transition a été réalisée.

Dans le cas FreeBSD, notre mécanisme de librairie partagée se rapproche plus des style de mécanisme de librairie partagée des SunOS de Sun, et de la sorte, est très simple à utiliser. Quoiqu'il en soit, à partir de 3.0, FreeBSD supportera officiellement les binaires ELF comme format par défaut. Même si les formats exécutables a.out nous ont beaucoup servis, les gens du GNU auteurs des outils de compilation que nous utilisons ont arrêté leur supports pour le format a.out. Cela nous a forcé à maintenir des versions divergentes du compilateur et de l'éditeur de liens, et nous a empêché de bénéficier des derniers efforts du développement GNU. Et puis, les demandes de ISO-C++, notemment pour les constructeurs et les destructeurs, nous ont aussi conduit à supporter de l' ELF natif pour les futures release de FreeBSD.

Précédent | Niveau supérieur | Suivant
Chapitre 12. Questions diverses. **Mise à jour en cours** | Sommaire | 12.3. Pourquoi chmod ne veulent pas changer les permissions sur les liens symboliques ?

Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.