Compilation

Le pré-processing consiste à substituer toutes les macros présentes dans le code par leur valeur: #ifdef, #define, #include, etc. Voici un petit exemple de code sur lequel le préprocesseur va fonctionner:

/*
 * Exemple d'utilisation de macros
 */

#include <stdio.h>
#define BORNE_MAX      100
#define MAX(a,b)       ((a)>(b)?(a):(b))

int table [BORNE_MAX];

int main() {
  int i;

  for (i=0; i < BORNE_MAX; i++)
          table [i]=i;
#ifdef DEBUG
  printf ("DEBUG : table[10]=%d\n", table[10]);
#endif
  return 0;
}
       

Les personnes de nature curieuse pourront examiner le code obtenu à l'issue du pré-processing avec l'option -E du compilateur:

        % gcc -E fichier.c > fichier.E
       

L'étape de compilation par elle-même. Elle travaille sur le fichier résultat du préprocessing, et produit un fichier texte contenu du code en langage d'assemblage spécifique à la machine sur laquelle vous compilez.

L'étape d'assemblage prend le fichier précédent, et génère du code machine. Le fichier produit est appelé fichier objet, et se reconnait en général par son extension .o.

L'édition de liens prend un ensemble de fichiers objets pour produire un programme exécutable.

Cette option indique au compilateur de s'arrêter après la génération du fichier objet (de ne pas faire l'édition de liens). Elle permet la compilation séparée.

Cette option indique le chemin de recherche pour trouver les fichiers inclus dans les macros #include <fichier.h>. Un certain nombre de répertoires sont prédéfinis et n'ont pas besoin d'être spécifiés. L'ordre des répertoires de recherche est important. Une variante existe: les macros #include "fichier.h" se limitent au répertoire courant.

Cette option indique le nom de l'exécutable qui sera généré à l'édition de liens. Par défaut, si on ne précise rien, l'exécutable est appelé a.out en référence au format dans lequel est écrit ce fichier.

Cette option rajoute des informations supplémentaires dans chacun des fichiers produits pour faciliter la tache de debuggage. Cela permet en utilisant un debugger (par exemple gdb) d'avoir accès aux noms de variables utilisées dans le source, de savoir pour chaque instruction machine exécutée à quel fichier source, et à quelle ligne de code cela correspond. La taille des fichiers ainsi générés augmente sensiblement, on évitera donc de laisser trainer ces options en cycle de production ou lorsque l'on fournit un produit fini.

Cette option indique si l'on souhaite produire un code optimisé. La valeur n indique le niveau d'optimisation souhaité, de zéro (pas d'optimisation, jusqu'à 6 ou plus, ceci dépend du compilateur). Chaque niveau correspond à la sélection d'un groupe d'options d'optimisation indépendantes. On peut choisir une optimisation specifique en précisant l'option -foptimisation_specifique ou au contraire pour interdire une optimisation spécifique par -fno_optimisation_specifique. Chaque option d'optimisation est décrite abondamment dans les pages du manuel en ligne du compilateur. Il est possible de mixer les options d'optimisation et de débugage (-g -O2 par exemple), mais cela n'est pas recommendé car cela rend le code délicat à débugger. L'optimiseur se réserve le droit de supprimer des variables inutiles, de précalculer des expressions, de changer l'ordre d'exécution des instructions. Toutes ces modifications perturbent l'utilisateur qui s'attend à avoir une exécution séquentielle des lignes de son code source sous le debugger.

Cette option permet de définir des constantes ayant une valeur pour le préprocesseur. L'exemple précédent montre que le compilateur ajoute lui-même un grand nombre de ces constantes, permettant de caractériser le système sur lequel la compilation s'exécute (compilation conditionnelle).

Ces options sont utilisées pour l'édition de liens. Elles permettent d'inclure des fichiers objets supplémentaires à ceux que l'on a compilé. Ces fichiers objets sont regroupés dans un fichier unique, nommé librairie. Une librairie est donc un ensemble de fichiers .o. Elle peut être liée statiquement ou dynamiquement à l'exécutable.

Dans le premier cas, le contenu de la librairie est ajouté dans le fichier exécutable une fois pour toute. Cela rend l'exécutable self-contained. Tout le code dont il a besoin pour fonctionner est inclus dans le fichier executable. Le désavantage de cette méthode est que la mise à jour de la librairie ne pourra se faire que par une recompilation de notre fichier source qui est à la charge de l'utilisateur.

Dans le second cas, l'exécutable ne contient qu'un lien vers cette librairie. Il est donc de plus petite taille. Il n'y a cependant pas de miracle, le code de la librairie devra pourtant être chargé au moment de l'exécution (on parle de runtime). Pour cela, une variable d'environnement LD_LIBRARY_PATH contient une liste de répertoire dans laquelle le loader dynamique recherchera la librairie souhaitée au lancement de l'exécutable. L'intérêt est d'avoir des exécutables qui ne dupliquent pas le code d'une même librairie, et de pouvoir mettre à jour une librairie sans avoir besoin de recompiler les programmes qui l'utilisent (pour peu que cette librairie continue d'utiliser la même API, Application Programming Interface. Des numéros de versions majeurs et mineurs sont utilisés pour gérer la compatibilité entre les versions d'une librarie).

L'option -Ldirectory indique le directory où le linker doit rechercher la librairie (au moment de l'édition des liens), et l'option -llibrary precise le nom de cette librairie. Selon les architectures, le fichier aura comme nom liblibrary.so pour une librairie dynamique ou liblibrary.a pour une librairie statique.