FAQ CConsultez toutes les FAQ

Le compilateur (en anglais : compiler) est le programme qui traduit les fichiers source (unités de compilation) en fichiers objet (unités compilées). Un fichier objet est un fichier qui contient, entre autres, l'équivalent en langage machine de ce qui était contenu dans le fichier source original. Le compilateur ne produit pas de fichier exécutable, cette tâche étant confiée à l'éditeur de liens.

L'éditeur de liens (en anglais : linker) est le programme qui lie les fichiers objet entre-eux pour produire un fichier exécutable. L'ensemble préprocesseur + compilateur + éditeur de liens constituent ce qu'on appelle le plus souvent un « compilateur » (ici, minimal certes), car c'est en effet généralement ce dernier que le programmeur invoque pour traduire ses fichiers source en fichiers exécutables. Les 3 grandes phases de cette « compilation » (traduction), rappelons-le, sont :

• la précompilation, effectuée par le préprocesseur ;
• la compilation proprement dite, effectuée par le compilateur ;
• l'édition des liens, effectuée par l'éditeur de liens.
  

Il peut arriver, souvent ou rarement selon votre domaine, que vous ayez besoin de compiler un programme pour une plateforme différente de celle qui est utilisée pour le développement. Par exemple, pour créer une application pour un téléphone portable, vous n'allez certainement pas programmer avec votre téléphone. Vous développerez plutôt votre application toujours sur ordinateur, mais la compilerez pour le téléphone et non pour votre système. C'est la cross-compilation.

Les fichiers exécutables des systèmes tels que Windows, Linux, etc. ne contiennent pas que du code exécutable par le processeur. Ils contiennent aussi, entre autres, un en-tête qui décrit le fichier (type du fichier, localisation du code exécutable dans le fichier, localisation des ressources dans le fichier, etc.). Lorsqu'on demande donc à les exécuter, le système va tout d'abord analyser le fichier, le valider, localiser la partie exécutable, la placer en mémoire avant d'enfin demander au processeur d'exécuter le programme ainsi chargé. Un exécutable au format binaire plat (en anglais : flat binary) est un fichier qui ne contient que du code directement exploitable par le processeur.

L'édition statique des liens est une technique qui permet qu'une application soit distribuée sans fichiers de bibliothèque (.dll, .so, .dylib). En fait, l'édition statique les inclut dans l'exécutable. On parle aussi de « compilation statique ».

Cette méthode a des avantages comme des inconvénients. Elle rend les exécutables plus lourds, mais elle élimine les indirections (les renvois vers telle ou telle bibliothèque, tout est inclus dans l'exécutable !) et la nécessité de charger des bibliothèques au démarrage. Les applications liées statiquement aux différentes bibliothèques démarrent donc plus vite. Le problème, c'est que si plusieurs applications utilisent les mêmes bibliothèques, une copie de chaque bibliothèque sera créée en mémoire pour chaque application, ce qui résulte en une utilisation énorme de mémoire.

Parmi les inconvénients, comptons aussi la difficulté de mise à jour : si même seule une bibliothèque a été mise à jour, c'est tout l'exécutable qu'il faudra recompiler pour utiliser la nouvelle version !

L'édition dynamique des liens lie votre application à une bibliothèque partagée (DLL sous Windows : Dynamic Link Library, SO sous Linux : Shared Object, DYLIB sous Mac OS : Dynamic Library) chargée à l'exécution. En fait, si la bibliothèque (en anglais : library d'où la formulation « une lib » pour désigner « une bibliothèque ») est déjà chargée en mémoire, elle ne le sera pas à nouveau. Ceci permet d'économiser de la mémoire. Toutefois, même dans ce cas, les systèmes d'exploitation modernes fonctionnant exclusivement en mode protégé, les applications « mappent » (associent, attachent) toujours les bibliothèques dans leur espace d'adressage avant de les utiliser. Cela signifie que même s'il est vrai qu'il n'existe qu'une seule instance de la bibliothèque en mémoire physique, chaque application se comporte comme si elle était la seule à l'utiliser.

Le chargement des applications qui se lient dynamiquement aux différentes bibliothèques est cependant plus lent que le chargement des applications liées statiquement : il faut que l'OS charge aussi les bibliothèques puis les initialise avant que l'application puisse s'exécuter.

La mise à jour des applications devient cependant aisée (si seule l'implémentation, c'est-à-dire le corps des fonctions, a changé) : il suffit de remplacer les fichiers qui ont subi des modifications par leurs nouvelles versions. Si c'est l'interface même (c'est-à-dire le prototype) d'une qui fonction a changé, ou si une fonction a été supprimée, ce qui est rare, car les développeurs se soucient souvent du problème de compatibilité (en pratique, s'il doit y avoir des changements profonds, on ajoute des fonctions plutôt que de modifier le prototype des fonctions déjà existantes), alors il faudra évidemment recoder l'application pour l'adapter à la nouvelle version.

Au niveau de la compilation, les applications apprennent les différentes bibliothèques avec lesquelles elles devront se lier à l'exécution grâce à une bibliothèque d'importation (un fichier .lib ou .a) qui indique le nom de la bibliothèque qui lui est associée et qui liste les fonctions contenues dans cette bibliothèque sans leurs implémentations (elles, stockées dans la bibliothèque). Cela rend donc les applications plus légères.