3. Compiler avec cc

3.1. Questions et problèmes cc

Q. J'essaie d'écrire un programme qui utilise la fonction sin() et j'obtiens une erreur qui ressemble à ce qui suit. Qu'est-ce que cela veut dire?

/var/tmp/cc0143941.o: Undefined symbol `_sin' referenced from text segment

R. Quand vous utilisez des fonctions mathématiques telles que sin(), vous devez dire à cc d'inclure la bibliothèque mathématique à l'édition de liens, comme ceci:

% cc -o foobar foobar.c -lm

Q. D'accord, j'ai écrit ce petit programme pour m'entraîner à utiliser -lm. Il ne fait que calculer 2.1 à la puissance 6:

#include <stdio.h>

int main() {
      float f;

      f = pow(2.1, 6);
      printf("2.1 ^ 6 = %f\n", f);
      return 0;
}
           

% cc temp.c -lm

% ./a.out
2.1 ^ 6 = 1023.000000

Ce n'est pas la bonne réponse! Que se passe-t-il?

R. Quand le compilateur voit que vous appelez une fonction, il regarde s'il en a déjà vu un prototype. Si ce n'est pas le cas, il suppose que la fonction retourne un int - entier, ce qui n'est évidemment pas ce que vous souhaitez dans ce cas.

Q. Comment alors régler ce problème?

R. Les prototypes des fonctions mathématiques sont dans math.h. Si vous incluez ce fichier, le compilateur trouvera le prototype et cessera de vous fournir un résultat bizarre!

#include <math.h>
#include <stdio.h>

int main() {
...
           

Après l'avoir recompilé de la même façon qu'auparavant, exécutez-le:

% ./a.out
2.1 ^ 6 = 85.766121

Si vous utilisez la moindre fonction mathématique, incluez toujours math.h et n'oubliez pas d'utiliser la bibliothèque mathématique à l'édition de liens.

Q. J'ai compilé un fichier appelé foobar.c et je ne trouve pas d'exécutable appelé foobar. Où est-il passé?

R. N'oubliez pas, cc appellera l'exécutable a.out à moins que vous ne lui disiez de faire autrement. Utilisez l'option -o nom_de_fichier:

% cc -o foobar foobar.c

Q. OK, si j'ai un exécutable appelé foobar, je le vois avec ls, mais quand je tape foobar sur la ligne de commande, il me dit que le fichier n'existe pas. Pourquoi ne le trouve-t-il pas?

R. A l'inverse de MS-DOS, Unix ne regarde pas dans le répertoire courant quand il cherche le programme que vous voulez exécuter, à moins que vous ne le lui disiez. Soit tapez ./foobar, ce qui veut dire “exécuter le fichier appelé foobar du répertoire courant”, ou modifiez votre variable d'environnement PATH pour qu'elle ressemble à:

bin:/usr/bin:/usr/local/bin:.

Q. J'ai appelé mon exécutable test, mais il ne se passe rien quand je le lance. Pourquoi?

R. Il y a un programme appelé test dans /usr/bin sur la plupart des systèmes Unix et c'est celui-là que trouve l'interpréteur de commandes avant de regarder dans le répertoire courant. Soit tapez:

% ./test

Q. J'ai compilé et tout a commencé à fonctionner correctement, puis il y a eu une erreur et il m'a dit quelque chose à propos de “core dumped”. Qu'est-ce que cela veut dire?

A. L'expression core dump date des tous premiers jours d'Unix, quand les machines utilisaient la mémoire centrale - “core memory” pour stocker les informations. Essentiellement, si le programme “plantait” dans certaines conditions, le système enregistrait sur disque le contenu de la mémoire centrale dans un fichier appelé core, que le programmeur pouvait ensuite disséquer pour trouver où les choses avaient mal tournées.

Q. Fascinant, mais que suis-je censé faire maintenant?

A. Servez-vous de gdb pour analyser l'image mémoire (Reportez-vous à la section Déboguer).

R. Quand mon programme a généré une image mémoire, il a dit quelque chose à propose de “segmentation fault” - “erreur de segmentation”. Qu'est-ce que c'est?

Q. Cela signifie essentiellement que votre programme a essayé d'effectuer une quelconque opération illégale sur la mémoire; Unix est conçu pour protéger le système d'exploitation des programmes mal éduqués.

Les raisons les plus courantes en sont:

• Essayer d'écrire en mémoire adressée par un pointeur NULL, e.g.:

  
  char *foo = NULL;
  strcpy(foo, "bang!");
                
  

  
  
  

• Utiliser un pointeur qui n'a pas été initialisé, e.g.:

  
  char *foo;
  strcpy(foo, "bang!");
                
  

  Le pointeur aura une valeur aléatoire qui, avec de la chance, adressera une zone mémoire non accessible à votre programme, de sorte que le noyau tuera ce dernier avant qu'il ne provoque de dégât. Si vous manquez de chance, il pointera quelque part à l'intérieur de votre programme et endommagera l'une de vos structures de données, provoquant un dysfonctionnement mystérieux de votre programme.
  
  

• Tenter d'accéder au-delà du dernier élément d'un tableau, e.g.:

  
  int bar[20];
  bar[27] = 6;
              
  

  
  
  

• Essayer d'enregistrer quelque chose dans une zone de mémoire accessible en lecture seule, e.g.:

  
  char *foo = "Mon texte";
  strcpy(foo, "bang!");
                
  

  Les compilateurs Unix stockent souvent les chaînes de caractères constantes comme "Mon texte" en mémoire accessible en lecture seule.
  
  

• Utiliser incorrectement les fonctions malloc() et free(), e.g.:

  
  char bar[80];
  free(bar);
               
  

  ou:

  
  char *foo = malloc(27);
  free(foo);
  free(foo);
               
  

  
  
  

Commettre l'une de ces fautes ne provoquera pas toujours une erreur, mais ce sont malgré tout des choses à ne pas faire. Certains systèmes et compilateurs sont plus tolérants que d'autres, ce qui fait que des programmes qui s'exécutent correctement sur un système peuvent ne plus fonctionner sur un autre.

Q. Parfois, le programme provoque la génération d'une image mémoire avec le message “bus error”. Mon manuel Unix dit qu'il s'agit d'un erreur matériel, mais l'ordinateur fonctionne apparemment correctement. Est-ce vrai?

R. Fort heureusement, non (à moins bien sûr que vous n'ayez aussi un problème matériel). C'est habituellement une autre façon de dire que vous avez accédé incorrectement à la mémoire.

Q. Il me semble que cette histoire de core dump peut être très utile, si je peux la provoquer quand je veux. Est-ce possible, ou dois-je attendre qu'il se produise une erreur?

R. Oui, allez simplement sur une autre console ou fenêtre xterm et tapez:

% ps

% kill -ABRT pid

C'est par exemple utile si votre programme est parti dans une boucle infinie. Au cas où votre programme piégerait les interruptions SIGABRT, il y a plusieurs autres signaux qui auront le même effet.