Compte rendu du TP n4 (suite) et TP n5

Programmation C sous Linux

RAHAL Majda Nafissa - 23/04/2012

Exercice 1 :
1. On cre un rpertoire TP3 dans le home directory l'aide de :
mkdirTP3
2. On recopie le code puis on enregistre le fichier sous le nom test.c
3. On gnre le code objet avec la commande gccctest.c
Ce qui aura pour effet de crer un fichier test.o contenant le code objet gnr.
4. On fait une dition de liens dynamique du programme en excutant :
gccotest.dyntest.o
Notons que l'dition de liens est une tape indispensable de la cration d'un
excutable, et qui permet de lier les fichiers objets avec les fichiers d'une ou
plusieurs bibliothques.
On distingue 2 types d'dition de liens :
- statique : o le fichier objet et la bibliothque sont lis dans le mme fichier
excutable. On ramne le code complet de la bibliothque et on l'installe dans
l'excutable.
- dynamique : o le fichier objet est li avec la bibliothque, mais n'est pas dans le
mme fichier excutable ; les liens sont tablis lors du lancement de l'excutable.
On mentionne seulement la bibliothque, on ne l'installe pas.
La premire technique nous donne l'avantage de pouvoir utiliser notre excutable
sur n'importe quelle machine (mme si les bibliothques dont nous avons besoin
n'y sont pas installes), mais elle prsente l'inconvnient de la taille (on importe
toute la bibliothque). A contrario, la deuxime nous permet de gagner en espace
mmoire mais ce moment l, nous ne pourrons utiliser notre excutable que sur
les machines o il y a les bibliothques ncessaires.
Par dfaut, l'dition de liens est dynamique lorsque l'on excute notre commande.
L'option o sert renommer l'excutable en test.dyn. Si on ne l'avait pas mise, le
fichier cr serait nomm a.out
5. On affiche les bibliothques partages requises par notre excutable comme ceci :
lddtest.dyn
Ce qui affichera :
linuxgate.so.1=>(0x007b9000)
libc.so.6=>/lib/i386linuxgnu/libc.so.6(0x0040c000)
/lib/ldlinux.so.2(0x006f2000)
linuxgate.so.1 est une bibliothque virtuelle qu'on rajoute pour excuter plus
rapidement les appels systme. so quivaut Shared Object (qui joue le mme rle
que les fichier .dll sous Windows), linux indique qu'elle est cre par le noyau.
/lib/ldlinux.so.2 est le loader dynamique de Linux, et qui s'occupe de
localiser les bibliothques dynamiques dont a besoin le programme et de les
page 1

charger.
6. Ralisation de l'dition de liens statique :
gccstaticotest.stattest.o
Il suffit donc d'ajouter l'option static gcc pour que l'dition de liens soit
statique.
7. Comparaison des tailles des fichiers test.dyn et test.stat :
test.dyn:6,9Ko|test.stat:605Ko
On remarque que l'excutable cr avec une dition de liens statique est cent fois
plus volumineux que celui cr avec une dition de liens dynamique. Ceci est d au
fait que test.stat intgre le code de toutes les bibliothques utilises dans le
programme alors que pour test.dyn on cre un lien vers les bibliothques dont
on a besoin mais on ne les importe pas dans l'excutable.
8. On ouvre 2 terminaux et on visualise le contenu des fichiers test.o et test.dyn
l'aide des commandes suivantes :
objdumpdtest.o
objdumpdtest.dyn
Notons que objdump sert afficher le code objet dsassembl (option d pour
disassemble) de ces fichiers.
On remarque que le code de test.dyn est beaucoup plus long que celui de test.o
On constate aussi que pour les fonctions, on a :
test.o

test.dyn
Fonction add

call29<main+0x29>
Le systme donne la fonction un nom
interne (29) et nous renseigne sur son
offset (adresse relative partir du dbut
du main).

call8048421<add>
L par contre, le symbole a t rsolu : le nom
a t remplac et est maintenant add. On lui a
aussi associ l'adresse effective de la premire
instruction de la fonction.

Fonction printf
call52<main+0x52>
Pareillement, le nom interne 52 est
donn la fonction et on nous informe
sur son offset.

call80482f4<printf@plt>
Ici aussi, le symbole a t rsolu, la fonction a
maintenant le nom printf.
Une adresse effective lui est associe et qui
reprsente l'adresse de la premire instruction
de la fonction par rapport au dbut du
programme.

Ce qui confirme ce qu'on a vu en cours ; savoir que ce n'est qu'au moment de

l'tape d'dition de liens que le branchement vers les fonctions externes (issues d'une ou
de plusieurs bibliothques) est fait.

9. Modifions maintenant le programme prcdent pour le rendre modulaire, et ce de

la manire suivante :
page 2

add.c
#include"add.h"

add.h

test.c
#include<stdio.h>
intadd(intx,inty); #include"add.h"
intadd(intx,inty)

{returnx+y;}
intmain(){
inta=3,b=4,c;
c=add(a,b);
printf("%d+%d=%d\n",
a,b,c);
return0;}
10. La cration de l'excutable test ncessite le fichier objet de add.c, que l'on cre
avec la commande :
gccctest.cadd.c
En ralit, ce n'est qu' l'tape de l'dition de liens que l'on a besoin des 3 fichiers,
car c'est l o sont fait les liens entre le fichiers et les bibliothques. la
compilation, on aurait pu faire gccctest.c, on n'aurait pas eu d'erreur vu que
le compilateur n'a besoin que des prototypes des fonctions (pas encore de leur
code).
11. On cre l'excutable test l'aide de la commande suivante :
gccotesttest.oadd.o
Et on l'excute avec ./test, on obtient comme rsultat :
3+4=7
12. Cration d'un fichier Makefile permettant de construire l'excutable test :
La commande make permet d'automatiser la compilation d'excutables. En effet,
elle se charge de recompiler tous les fichiers (modules d'un programme/projet) qui
ont t modifis. Pour travailler, la commande make a besoin d'un fichier makefile
contenant les actions et dpendances du programme.
Dans le cas de notre programme test, le makefile peut se prsenter de la manire
suivante :
#Variablesgnrales
OBJS=test.oadd.o#touslesfichiersobjetsncessairesla
EXEC=test
CC=gcc

constructiondel'excutable
#variablecontenantlenomdel'excutable
#nomducompilateurutiliser

#Rglesdeconstructiondel'excutable
test:$(OBJS)
$(CC)$(OBJS)o$(EXEC)
#Rglesdeconstructiondesfichiersobjets
add.o:add.cadd.h
$(CC)cadd.c
test.o:
$(CC)ctest.c
La commande make substituera les variables sus-cites par leurs valeurs dans les
page 3

rgles ou actions. l'excution de cette commande, on aura :

make:testestjour.
13. On cre un fichier sub.c avec le code donn, ainsi qu'un fichier sub.h contenant
le prototype de la fonction sub ; savoir : intsub(intx,inty);
14. On cre une bibliothque statique libarithm.a l'aide de la commande donne
(en ayant pris le soin de crer le fichier objet sub.o auparavant).
Ceci aura pour effet de crer une archive du nom de libarithm.a, et qui fait
office de bibliothque de fonctions arithmtiques.
15. On refait l'dition de liens avec la bibliothque cre l'instant, comme ceci :
gccotestlibstattest.olibarithm.a
On remarque en excutant le fichier testlibstat que l'on a exactement le mme
rsultat que dans la technique prcdente, savoir 3+4=7.
16. On cre un rpertoire lib dans TP3 comme cela :
mkdirTP3/lib
On y place la bibliothque en question, en excutant mvlibarithm.aTP3/lib
17. On cre une bibliothque dynamique libarithm.so avec la commande donne.
Notons que l'option shared indique que nous voulons produire un objet partag
qui peut tre li avec d'autres objets pour former un excutable.
18. On refait l'dition de liens avec la bibliothque dynamique, ainsi :
gccotestlibdyntest.olibarithm.so
19. L'excution de testlibdyn est impossible, le shell nous signale :

./testlibdyn:errorwhileloadingsharedlibraries:libarithm.so:
cannotopensharedobjectfile:Nosuchfileordirectory

Pour remdier ce problme, nous avons besoin d'installer cette librairie au

pralable. Pour ce faire, on copie d'abord la librairie dans le rpertoire lib :
mvlibarithm.soTP3/lib
Puis, on excute la commande suivante, qui va crer le lien avec la bibliothque
dynamique. L'option n sert prciser le rpertoire o se trouve la bibliothque.
ldconfignTP3/lib
Enfin, on re-compile notre excutable (avec la mme commande prcdente) mais
maintenant, il s'excute sans problmes lorsque l'on tape ./testlibdyn
et donne le rsultat escompt : 3+4=7.

page 4