Page 1 sur 9
Sommaire
1.- La cr ation d'un programme. Introduction. ................................................................................................. 2
2.- Rapide historique des m thodes de cr ation de programmes. ..................................................................... 2
3.- Qu'est-ce qu'une biblioth que ? ................................................................................................................... 3
4.- Types de biblioth ques. ............................................................................................................................... 3
5.- L' dition de liens sous Linux ....................................................................................................................... 4
6.- L' dition dynamique des liens et le chargement des biblioth ques partag es ............................................. 4
7.- soname. Versions de biblioth ques partag es. Compatibilit . .................................................................... 5
8.- ldconfig(8) ................................................................................................................................................... 6
9.- Cr er une biblioth que partag e .................................................................................................................. 6
9.1.- Compilation du source ...................................................................................................................... 6
9.2.- Edition des liens................................................................................................................................ 6
9.3.- Installation de la biblioth que........................................................................................................... 7
10.- Cr er une biblioth que statique ................................................................................................................. 7
10.1.- Compilation du source .................................................................................................................... 8
10.2.- Edition des liens.............................................................................................................................. 8
10.3.- Installation de la biblioth que......................................................................................................... 8
11.- Liens statiques ou dynamiques ? ............................................................................................................... 8
Page 2 sur 9
1.- La cr ation d'un programme. Introduction.
La cr ation d'un programme et les outils de d veloppement actuels r sultent de l' volution des habitudes et de
l'exp rience des programmeurs et cr ateurs.
La cr ation d'un programme implique les tapes suivantes:
criture du code source dans un langage de haut niveau avec un diteur de texte. Les programmes importants sont
difficiles g rer s'ils r sident dans un unique fichier. C'est pourquoi le code source est souvent divis en modules
fonctionnels, form s d'un ou plusieurs fichiers de code source. Remarquons que ces modules peuvent tre crits dans
des langages diff rents, de fa on s'adapter la t che r aliser.
Apr s criture des fichiers de code source du programme, l' tape de traduction permet d'obtenir des instructions
ex cutables par la machine. C'est le code objet, qui r alise les m mes op rations que le code source, mais dans un
langage directement exploitable par la machine. Cette tape de traduction de code source en code objet est connue
sous le terme de compilation. Une session de compilation n'implique g n ralement qu'une partie du programme, c'est
dire un ou quelques fichiers source. Le code objet r sultant peut contenir un programme, un sous-programme, des
variables, etc. -- de fa on plus g n rale des l ments de programmes traduits et pr ts pour le traitement suivant.
Lorsque tous les fichiers de code objet du programme sont g n r s, l' tape suivante consiste lier -regrouper- tous les
morceaux du puzzle. L' diteur de lien est l'utilitaire responsable de cette t che. En particulier, toutes les r f rences
entre les diff rents modules de code sont r solues (comme les appels de sous-programmes ou les r f rences des
variables d finies dans d'autres modules). Le r sultat est un programme qui peut normalement tre charg et ex cut
directement.
L'ex cution d'un programme est r alis e par une partie essentielle du syst me d'exploitation ; pour Linux, il s'agitde
l'appel la fonction syst me exec(). Cette fonction cherche le fichier, alloue de la m moire au processus, charge
certaines parties particuli res du fichier (celles qui contiennent le code et certaines variables), et finalement transf re
le contr le du CPU au d but du programme (g n ralement rep r dans le fichier ex cutable lui-m me).
2.- Rapide historique des m thodes de cr ation de programmes.
La mani re de cr er des programmes a constamment volu afin de parvenir une ex cution plus efficace ou une
meilleure utilisation des ressources du syst me.
A l'origine, les programmes taient directement crits en code machine. Plus tard, il est apparu que l' criture dans un
langage de haut niveau suivie d'une traduction en code machine pouvait tre automatis e du fait de la nature
syst matique du proc d de traduction. Cette m thode a grandement am lior la productivit du d veloppement des
logiciels.
A l'av nement de la compilation (j'ai volontairement simplifi l' volution de la compilation, qui en r alit a t une
tape difficile cause de la grande complexit de la t che), la cr ation d'un programme consistait donc g n rer un
fichier de code source, le compiler puis finalement l'ex cuter.
Il fut n anmoins rapidement vident que la compilation tait gourmande en terme de ressources, en particulier en
temps CPU ; il apparut aussi que beaucoup de fonctions taient communes de nombreux programmes. D'autre part,
une modification m me mineure du code source impliquait la recompilation de l'ensemble du code source, c'est dire
recompiler des parties de code inchang es pour obtenir le programme modifi .
Ceci justifia l'introduction de la compilation par modules. Le principe consistait s parer le programme principal des
fonctions utilitaires fr quemment utilis es, qui taient alors compil es et archiv es dans un fichier sp cial (le
pr curseur des biblioth ques).
Il tait alors possible de d velopper des programmes utilisant ces fonctions sans l'effort inutile de recopier leur code
encore et toujours. La m thode demeurait n anmoins complexe car il tait n cessaire l' dition de liens de regrouper
tous les morceaux, que le programmeur devait identifier (cela impliquait ventuellement d'inclure des fonctions
inconnues, utilis es ou appel es par les fonctions choisies).
Page 3 sur 9
3.- Qu'est-ce qu'une biblioth que ?
Les probl mes rencontr s ont conduit la cr ation des biblioth ques. Il ne s'agit en fait que d'un autre type de fichier
(plus exactement une archive, de type tar(1)ou cpio(1)) avec la caract ristique que l' diteur de lien reconna t son
format. Quand on sp cifie une biblioth que archive, L'EDITEUR DE LIEN NE SELECTIONNE QUE LES
MODULES REELLEMENT UTILISES PAR LE PROGRAMME, et exclue le reste. Un nouvel avantage apparaissait
Publicité
donc. Il tait maintenant possible de d velopper des programmes utilisant des biblioth ques comportant un grand
nombre de fonctions, sans que le programmeur ait conna tre les d pendances entre les fonctions de la biblioth que.
La biblioth que telle que nous venons de la pr senter a peu volu . Simplement, le fichier comporte une zone
suppl mentaire qui appara t au d but de l'archive et contient une description des modules et identifieurs permettant
l' diteur de liens de r soudre les r f rences correspondantes sans avoir parcourir toute la biblioth que. Cette zone
suppl mentaire, appel e table des symboles de la biblioth que archive, est ajout par la commande ranlib(1) de Linux.
Les biblioth ques d crites jusqu'ici sont d nomm es BIBLIOTHEQUES STATIQUES.
Un progr s significatif est apparu avec les premiers syst mes multit ches: le partage du code. Si, sur un m me
syst me, deux copies d'un code identique doivent tre ex cut es simultan ment, il appara t int ressant que les deux
processus puissent partager le code, puisque normalement un programme ne modifie pas son code. Cette id e limine
les copies multiples en m moire, et donc conomise des quantit s de m moire importantes, en particulier sur les gros
syst mes multi-utilisateurs.
Poussant plus avant cette innovation, quelqu'un (je ne sais qui il/elle tait, mais son id e tait excellente ;-) r alisa que
tr s souvent, plusieurs programmes utilisent la m me biblioth que, mais puisque les programmes sont diff rents, les
portions de la biblioth que utilis es peuvent tre diff rentes. De plus, le code principal est diff rent (puisque ce sont
deux programmes distincts). L'id e tait que des programmes distincts utilisant une m me biblioth que puissent
partager le code de cette biblioth que, conomisant ainsi encore plus de m moire. Maintenant, diff rents programmes
partagent le code de la biblioth que, sans avoir le m me code programme.
Cependant la d marche est maintenant plus compliqu e. En effet, l' dition des liens du code ex cutable du programme
ne peut plus tre compl tement r alis e, et les r f rences aux identifieurs de la biblioth que doivent tre r solues de
fa on dynamique lors du chargement du programme. L' diteur de liens (ld(1) sous Linux) reconna t qu'il s'agit d'une
biblioth que partag e et n'inclut pas le code correspondant dans le programme. Le syst me lui-m me, le noyau,
lorsqu'il lance exec() reconna t qu'il lance un programme utilisant des biblioth ques partag es, et ex cute un code
sp cial pour charger les biblioth ques partag es (allocation de m moire partag e pour les instructions, et de m moire
priv e pour les variables, etc.). Ce traitement est maintenant effectu pour chaque chargement de code ex cutable,
rendant la proc dure beaucoup plus complexe.
Bien entendu, lorsque l' diteur de liens rencontre une biblioth que simple, il ex cute les m mes traitements qu'avant.
La biblioth que partag e n'est pas une archive de fichiers contenant du code ex cutable, mais ressemble plut t un
fichier de code objet. Lors de l' dition des liens d'un programme avec une biblioth que partag e, l' diteur de liens ne
regarde pas dans la biblioth que pour v rifier si tel module doit tre ajout et tel autre ignor . Il v rifie simplement
que les r f rences peuvent tre r solues, et rep re lesquelles doivent tre ajout es par l'inclusion de la biblioth que. Il
serait possible de r aliser une biblioth que archive ar(1) de toutes les biblioth ques partag es,mais c'est rarement fait
car une biblioth que partag e est souvent le r sultat du lien de plusieurs modules en sorte que la biblioth que est
utilis e plus tard, lors de l'ex cution. Le nom de biblioth que partag e est peut tre mal choisi, il serait plus juste de
parler d'objets partag s (n anmoins nous conserverons le terme universellement utilis pour faciliter la
compr hension).
4.- Types de biblioth ques.
Comme nous l'avons vu, sous Linux il existe deux type de biblioth ques : statiques et partag es. Les biblioth ques
statiques sont des collections de modules regroup es dans une archive avec l'utilitaire ar(1) et index es par
ranlib(1). Ces modules sont g n ralement stock s dans un fichier nomm *.a par convention (je n'utilise pas le
Page 4 sur 9
terme d'extension car il n'a pas de signification sous Linux). L' diteur de liens reconnait la terminaison .a, effectue la
s lection des modules n cessaires au programme et ajoute le code correspondant, permettant de r soudre toutes les
r f rences ind termin es.
A l'oppos , les biblioth ques partag es ne sont pas des archives mais des objets relogeables, identifi s en tant que
biblioth ques partag es par un code special. Comme indiqu , l' diteur de liens ld(1) n'ajoute pas les modules dans
le code du programme, mais marque les identificateurs fournis par la biblioth que comme r solus, ajoute les
identificateurs n cessaires la biblioth que elle-m me, et continue sans ajouter de code, comme si le code concern
existait dans le code principal. L' diteur de liens ld(1) reconna t une biblioth que partag e par sa terminaison .so
(et non pas .so.xxx.yyy, nous reviendrons sur ce point plus loin).
5.- L' dition de liens sous Linux
Tous les programmes sont constitu s de modules li s pour former un ex cutable. L' diteur de liens sous Linux est
l'utilitaire ld(1).
ld(1) peut tre invoqu avec de nombreuses options qui modifient son fonctionnement ; nous nous restreindrons ici
aux options qui concernent les biblioth ques d'une mani re g n rale. ld(1) n'est pas appel directement par
l'utilisateur, mais par le compilateur gcc(1). Une connaissance l mentaire de son modus operandis nous aidera
mieux comprendre l'utilisation des biblioth ques sous Linux.
ld(1) maintient une liste d'objets qui doivent tre li s au programme. Ces objets peuvent tre donn s et appel s dans
n'importe quel ordre (*) tant que la convention pr c dente est repect e, c'est dire que le nom des biblioth ques
statiques se termine par .a et celui des biblioth ques partag es par .so (pas .so.xxx.yyy). Bien entendu, le nom
des fichiers objets simples se termine toujours par .o.
(*) Ce n'est pas tout fait exact. ld(1)inclue uniquement les modules qui r solvent les r f rences au moment de
l'inclusion, donc il pourrait demeurer une r f rence produite par un module inclu ult rieurement qui, puisqu'il
n'appara t pas encore lors de l'inclusion, peut rendre significatif l'ordre d'inclusion des biblioth ques.
D'autre part, ld(1) autorise l'ajout de biblioth ques standards gr ce aux options -l et -L.
Mais qu'entendons-nous par "biblioth que standard", quelle est la diff rence ? Aucune. Simplement, ld(1)
recherche les biblioth ques standard dans des endroits particuliers, alors quele code objet est recherch partir du
nom de fichier.
Les biblioth ques sont recherch es par d faut dans les r pertoires /lib et /usr/lib (j'ai n anmoins entendu dire
que selon la version ou l'impl mentation de ld(1), la recherche pouvait s'effectuer dans des r pertoires
Publicité
suppl mentaires). L'option -L permet d'ajouter des r pertoires au chemin de recherche par d faut. On l'utilise en
ajoutant -L repertoire pour chaque repertoire concern . Les biblioth ques standard sont indiqu es par
l'option -l Nom (ou Nom pr cise la biblioth que charger) et ld(1)cherchera, dans l'ordre, dans les r pertoires
correspondants, le fichier libNom.so. Si ce fichier n'existe pas, ld(1)essaiera libNom.a, c'est dire la version
statique.
Selon que ld(1) trouve libNom.so ou libNom.a, l' dition des liens est effectu e en tant que biblioth que
partag e ou statique.
6.- L' dition dynamique des liens et le chargement des biblioth ques
partag es
L' dition dynamique des liens est effectu e au chargement de l'ex cutable par un module sp cial (d'ailleurs ce module
est lui-m me une biblioth que partag e), appel /lib/ld-linux.so.
En r alit , il y a deux modules responsables du chargement des biblioth ques partag es : /lib/ld.so (pour les
biblioth ques l'ancien format a.out), et /lib/ld-linux.so (pour les biblioth ques au nouveau format ELF).
Page 5 sur 9
Ces modules sont particuliers, car ils doivent tre charg s chaque fois qu'un programme utilisant une biblioth que
partag e est lanc . Leurs noms sont pr -d finis (ils ne doivent donc pas tre renomm s ou d plac s du r pertoire /lib).
Si quelqu'un modifiait le nom /lib/ld-linux.so, le syst me deviendrait incapable d'ex cuter tous les
programmes faisant appel des biblioth ques partag es car ce module prend en charge la r solution de toutes les
r f rences ind termin es au moment de l'ex cution.
Ce module est second par le fichier /etc/ld.so.cache, qui indique pour chaque biblioth que le fichier
ex cutable le plus appropri . Nous reviendrons ce probl me plus loin.
7.- soname. Versions de biblioth ques partag es. Compatibilit .
Nous atteignons ici le point le plus d licat concernant les biblioth ques partag es.
Qui n'a jamais recu un message du type "library libX11.so.3 notfound" ? Il est parfaitement possible de
disposer de la biblioth que libX11.so.6, mais n anmoins de ne rien pouvoir faire. Comment se fait-il que
ld.so(8)
et
comme
libtoto.so.45.22.8 et ne reconnaisse pas libfoo.46.5.7 ?
libfoo.so.45.0.1
interchangeables
biblioth ques
reconnaisse
les
Sous Linux (et tous les syst mes d'exploitation impl mentant le format ex cutable ELF), les biblioth ques sont
identifi es par une cha ne de caract res qui les distinguent les unes des autres : le soname.
Le soname est incorpor dans la biblioth que elle-m me et la cha ne est d termin e l' dition des liens des objets
formant la biblioth que. A la cr ation de la biblioth que partag e, il faut utiliser l'option -soname pour donner une
valeur la cha ne de caract res.
La cha ne de caract res est utilis e au chargement pour identifier la biblioth que partag e charger et l'ex cutable
correspondant. Le d roulement est le suivant: ld-linux.so d tecte que le programme n cessite une biblioth que et
d termine son soname. Intervient ensuite/etc/ld.so.cache qui fournit le nom de fichier. Finalement, il
compare le soname au nom contenu dans la biblioth que, et s'ils sont identiques c'est fini! Sinon, la recherche
continue. En cas d' chec, une erreur est renvoy e.
Le soname permet d'assurer que la biblioth que correspond bien car ld-linux.so v rifie sa concordance avec le
fichier utilis . En cas de non concordance, nous obtenons le fameux message"libXXX.so.Y not found". Ce
que ld-linux.so recherche est le soname et c'est lui que fait r f rence le message d'erreur.
Cela porte confusion lorsqu'on change le nom de fichier dela biblioth que, et que l'erreur demeure. Mais ce serait
une mauvaise id e de modifier le soname, car il existe une convention dans la communaut Linux pour l'assigner.
Par convention, le soname d'une biblioth que doit identifier une biblioth que et son INTERFACE. Si des
modifications sont apport es qui n'affectent que le fonctionnement interne de la biblioth que, et donc que l'interface
enti re demeure intacte (nombre de fonctions, variables, param tres et valeur renvoy e pour les fonctions), alors les
deux biblioth ques sont interchangeables, et les modifications apport es sont qualifi es de mineures (les biblioth ques
sont compatibles et peuvent tre utilis es indiff remment). G n ralement dans ce cas, le num ro mineur de version de
biblioth que (qui n'appara t pas dans soname) est modifi , et une biblioth que peut priori etre remplac e par l'autre
sans probl me majeur.
Par contre, si l'on ajoute ou supprime des fonctions, ou d'une mani re plus g n rale si on MODIFIE L'INTERFACE
de la biblioth que, alors il est impossible de maintenir la compatibilit entre les deux versions (par exemple,
l' volution de X11R5 X11R6 se traduit par le passage de libX11.so.3 libX11.so.6, qui d finit de nouvelle fonctions
et donc modifie l'interface). Le changement de X11R6-v3.1.2 X11R6-v3.1.3 n'apportera probablement pas de
modification de l'interface, et la biblioth que portera le m me soname -bien que pour viter d' craser l'ancienne
biblioth que, la nouvelle portera un autre nom (pour cette raison, le num ro de version complet appara t dans le nom
de la biblioth que, mais seul le num ro majeur est utilis dans le soname).
8.- ldconfig(8)
Comme indiqu plus haut, /etc/ld.so.cache permet ld-linux.so de retrouver les biblioth ques. Ce
fichier au format binaire pour plus d'efficacit est cr par ldconfig(8).
Page 6 sur 9
Pour toutes les biblioth ques partag es trouv es dans les r pertoires sp cifi s /etc/ld.so.conf,ldconfig(8)
g n re un lien symbolique appel par le soname de la librairie. Il r alise cela de sorte que lorsque ld-linux.so
demande un nom de fichier, il s lectionne dans la liste des r pertoires un fichier avec le soname recherch . Ainsi, il
Publicité
est inutile d'ex cuter ldconfig(8) chaque ajout d'une biblioth que partag e ; on ne le lance que lorsqu'un
r pertoire est ajout la liste.
9.- Cr er une biblioth que partag e
Avant de cr er une biblioth que dynamique, il faut s'interroger sur l'utilit r elle. Il faut savoir que l'utilisation de
biblioth ques dynamiques g n re une surcharge du syst me pour diff rentes raisons :
Le chargement du programme s'effectue en plusieurs tapes ; une premi re pour le chargement du programme
principal, et une autre pour chaque biblioth que dynamique que le programme utilise.
Les biblioth ques dynamiques doivent contenir du code relogeable, puisque l'adresse r ellement affect e
l'int rieur de l'espace des adresses virtuelles n'est connue qu'au chargement. Le compilateur est oblig de
r server un registre pour m moriser la position de la biblioth que, ce qui diminue d'autant le nombre de
registres disponibles pour l'ex cution du code. C'est un moindre mal, et la surcharge correspondante est
estim e moins de 5% dans la plupart des cas.
Une biblioth que dynamique est adapt e lorsqu'elle est utilis e la plupart du temps par un ou plusieurs programmes
(ce qui vite le rechargement de la biblioth que la fin du programme l'ayant appel e, puisqu'elle demeure en
m moire tant qu'un programme l'utilise).
La biblioth que partag e est totalement charg e en m moire (et non pas uniquement les modules n cessaires),ce qui
implique qu'elle doit tre utilis e dans sa totalit . Lepire exemple serait une biblioth que partag e dont seule une
fonction serait utilis e, et dont 90% du code ne servirait presque jamais.
Un bon exemple de biblioth que dynamique est la bibliotheque C standard (utilis e par tous les programmes crits en
C). En moyenne, toutes les fonctions sont utilis es ici ou l .
Dans une biblioth que statique, il est inutile d'inclure les fonctions rarement utilis es ; il suffit de placer ces fonctions
dans leur propre module, et elles ne seront pas li es dans les programmes qui ne les r f rencent pas.
9.1.- Compilation du source
La compilation du code source est effectu e comme d'habitude, except l'option '-f PIC' (Position Independant
Code, code relogeable) pour produire un code objet qui pourra tre charg diff rentes positions dans l'espace des
adresses virtuelles du programme.
Cette tape est fondamentale car pour un programme li statiquement, la position des objets des biblioth ques est
d termin e l' dition des liens, c'est dire une fois pour toutes. L'ancien format d'ex cutable a.out ne permettait
pas de r aliser ce traitement, en cons quence chaque biblioth que partag e etait situ e une adresse fixe de l'espace
des adresses virtuelles. Il en r sultait des conflits quand un programme essayait d'utiliser deux biblioth ques partag es
et les chargeait des r gions non disjointes de la m moire virtuelle. Cela obligeait maintenir une liste indiquant pour
chaque biblioth que dynamique l' tendue des adresses occup es afin que personne d'autre ne l'utilise aussi.
Comme nous l'avons d j mentionn , l'inscription d'une biblioth que dynamique dans une liste officielle est inutile
car la position r ellement affect e est donn e dynamiquement au chargement. D'o la n cessit d'un code relogeable.
9.2.- Edition des liens
Page 7 sur 9
Apr s compilation de tous les objets, il faut les lier en invoquant une option permettant de produire un objet
susceptible d' tre charg dynamiquement.
gcc -shared -o libName.so.xxx.yyy.zzz -Wl, -soname, libName.so.xxx
Comme le lecteur peut le constater , l' dition de liens est classique, except l'ajout d'une s rie d'options qui justement
conduisent produire une biblioth que partag e. D taillons-les maintenant :
-shared,
cette option indique l' diteur de liens qu'il doit produire une biblioth que partag e, et donc qu'il y aura un
type particulier d'ex cutable dans le fichier de sortie correspondant la biblioth que.
-o libName.so.xxx.yyy.zzz,
est le nom du fichier de sortie. La convention de nom n'est pas obligatoire, mais est n anmoins conseill e en
particulier si cette librairie est destin e devenir standard.
-Wl, -soname, libName.so.xxx,
l'option -Wl indique au compilateur que les options suivantes (s par es par des virgules) sont
destin es l' diteur de liens. C'est le m canisme utilis par gcc(1) pour passer des options ld(1).
Ci-dessus nous passons les options suivantes l' diteur de lien :
-soname libName.so.xxx.
Cette option fixe le soname de la biblioth que, de facon qu'il puisse tre appel par les programmes la
requ rant.
9.3.- Installation de la biblioth que
Nous disposons d sormais du code ex cutable de la biblioth que. Il faut maintenant l'installer un endroit appropri
afin de pouvoir l'utiliser.
Pour compiler un programme utilisant notre nouvelle librairie, la ligne de commande serait :
gcc -o program libName.so.xxx.yyy.zzz
ou plus simplement, si la biblioth que a t install e la bonne place (/usr/lib):
gcc -o program -lName
(si la librairie avait t install e dans /usr/local/lib, il aurait suffit d'ajouter l'option -L/usr/local/lib).
Les tapes suivantes permettent d'installer la biblioth que :
Copier la biblioth que dans le r pertoire /lib ou /usr/lib. Si vous d cidez de l'installer dans un
r pertoire diff rent (par exemple /usr/local/lib), l' diteur de lien ld(1) ne la trouvera peut tre pas
automatiquement.
Ex cuter ldconfig(1) pour cr er
lien symboliquede libName.so.xxx.yyy.zzz vers
libName.so.xxx. Cette tape permettra galement de v rifier que les tapes pr c dentes ont t r alis es
avec succ s,et que la biblioth que est reconnue comme biblioth que dynamique. La facon dont les
Publicité
programmes sont li s l'ex cution n'est pas touch e par cette tape, seul le chargement des biblioth ques est
affect .
le
Cr er un lien symbolique de libName.so.xxx.yyyy.zzz(ou libName.so.xxx le soname) vers
libName.so de sorte que l' diteur de lien trouve la biblioth que avec l'option -l. pour que ce m canisme
fonctionne correctement, il est n cessaire que le nom de la biblioth que soit de la forme libName.so.
10.- Cr er une biblioth que statique
Si au contraire vous souhaitez cr er une biblioth que statique (ou si les deux versions sont n cessaires afin de pouvoir
offrir des programmes li s statiquement), nous allons maintenant d crire les tapes suivre.
Page 8 sur 9
Remarque : l' diteur de liens commence chercher la bibliotheque 0om dans un fichier libNom.so puis ensuite
libNom.a. Si les deux versions (statique et dynamique) de la librairie portent le m me nom, il ne sera g n ralement
pas possible de d terminer laquelle a t utilis e par l' diteur de liens .
Pour cette raison, quand les deux versions d'une m me biblioth que sont n cessaires, il est recommand d'utiliser le
nom libName_s.a pour la version statique, et libName.so pour la version partag e. Ainsi, la version statique
sera produite en invoquant:
gcc -o program -lName_s,
tandis que la version partag e sera obtenue par :
gcc -o program -lName.
10.1.- Compilation du source
Aucune mesure sp ciale n'est prendre pour compiler le(s) code(s) source. Puisque la position des objets est
d termin e l' dition des liens, il n'est pas n cessaire d'utiliser l'option -f PIC (n anmoins, conserver cette option ne
causera pas d'erreur).
10.2.- Edition des liens
Pour les biblioth ques statiques, il n'y a pas d' dition des liens. Tous les codes objets sont archiv s dans un fichier par
l'utilitaire ar(1). Ensuite, afin d'acc l rer la r solution des r f rences, il est conseill d'ex cuter ranlib(1) sur la
biblioth que. Ne pas ex cuter cette commande peut dans certains cas conduire la perte des liens d'un module
de l'ex cutable. En effet, quand le module est trait par l' diteur de liens lors de la construction de la biblioth que,
toutes les r f rences indirectes ne sont pas r solues imm diatement ; si le module est utilis par un autre module de la
biblioth que, il faudra plusieurs passages sur la biblioth que pour r soudre toutes les r f rences.
10.3.- Installation de la biblioth que
La biblioth que statique est nomm e libName.a si cette seule version suffit. Dans le cas o deux versions sont
n cessaires, je recommande de diff rencier les noms en appelant libName_s.a la biblioth que statique. Il sera
ainsi plus facile de contr ler quelle version de biblioth que est effectivement utilis e l' dition de liens.
L' dition des liens permet d'inclure l'option -static. Cette option contr le le chargement du module /lib/ld-
linux.so, et n'affecte pas l'ordre de recherche des librairies. En effet, si l'option -static est utilis e et si ld(1)
trouve une librairie partag e, il l'utilisera (au lieu de continuer chercher la librairie statique). Cela conduit des
erreurs l'ex cution cause de l'appel de routines qui n'appartiennent pas au code ex cutable -le module pour le
chargement automatique n'est pas li et donc ce traitement ne peut intervenir.
11.- Liens statiques ou dynamiques ?
Supposons que l'on souhaite distribuer un programme qui utilise une librairie que l'on est autoris distribuer
seulement si elle est inclue statiquement dans le programme, et pas sous une autre forme (c'est par exemple le cas
pour les applications developp es avec Motif).
A priori, deux options sont possibles pour distribuer ce type de logiciel. La premi re consiste cr er un ex cutable li
statiquement (en utilisant des biblioth ques .a). Lesprogrammes de ce type sont charg s en une seule fois et ne repose
sur aucune biblioth que du syst me (pas m me /lib/ld-linux.so). Cependant, ils ont l'inconv nient d' tre des
programmes tr s volumineux puisque le fichier doit contenir absolument tout le code n cessaire au fonctionnement du
programme. La deuxi me option consiste r aliser un programme li dynamiquement, o l'environnement
d'ex cution doit fournir toutes les biblioth ques dynamiques n cessaires. Le fichier ex cutable peut alors avoir une
tr s petite taille, avec cependant le risque que certaines biblioth ques ne soient pas install es (par exemple tout le
monde ne dispose pas de Motif).
Page 9 sur 9
En fait il existe une autre option, mi chemin entre les deux pr c dentes. Certaines librairies peuvent tre li es
statiquement, les autres dynamiquement. Il suffit alors de lier statiquement les biblioth ques posant probl me, et
dynamiquement toutes les autres. Cette derni re solution est une fa on tr s efficace de distribuer des logiciels.
Par exemple, on peut compiler trois versions diff rentes d'un programme de la mani re suivante :
gcc -static -o program.static program.o
-lm_s -lXm_s -lXt_s -lX11_s\
-lXmu_s -lXpm_s
gcc -o program.dynamic program.o
-lm -lXm -lXt -lX11 -lXmu -lXpm
gcc -o program.mixed program.o
-lm -lXm_s -lXt -lX11 -lXmu lXpm
Dans le troisi me cas seul la librairie Motif (-lXm_s)est li e statiquement, les autres sont li es dynamiquement.
L'environnement d'ex cution doit fournir les versions appropri es des biblioth ques libm.so.xx libXt.so.xx
libX11.so.xx libXmu.so.xxy libXpm.so.xx .