<HTML>
<HEAD>
<TITLE>Edition de liens</TITLE>
</HEAD>
<BODY>
<H1>6. <A NAME="s6"></A>Edition de liens</H1>
<P>
<A HREF="GCC-HOWTO.html#toc6">Contenu de cette section</A></P>
<P> Entre les deux formats de binaires incompatibles,
bibliothèques statiques et dynamiques, on peut comparer l'opération
d'édition de lien en fait à un jeu ou l'on se demanderait qu'est-ce
qui se passe lorsque je lance le programme ? Cette section n'est
pas vraiment simple...</P>
<P></P>
<P> Pour dissiper la confusion qui règne, nous allons nous baser sur
ce qui se passe lors d'exécution d'un programme, avec le chargement
dynamique. Vous verrez également la description de l'édition
de liens dynamiques, mais plus tard. Cette section est
dédiée à l'édition de liens qui intervient à la fin de la compilation.</P>
<P></P>
<H2>6.1 <A NAME="ss6.1"></A> Bibliothèques partagées contre bibliothèques statiques</H2>
<P> La dernière phase de construction d'un programme est de réaliser
l'édition de liens, ce qui consiste à assembler tous les morceaux
du programme et de chercher ceux qui sont manquants. Bien évidement,
beaucoup de programmes réalisent les mêmes opérations comme
ouvrir des fichiers par exemple, et ces pièces qui réalisent ce genre
d'opérations sont fournies sous la forme de bibliothèques. Sous Linux,
ces bibliothèques peuvent être trouvées dans les répertoires
<CODE>/lib</CODE> et<CODE>/usr/lib/</CODE> entre autres.</P>
<P>
<A NAME="index.65"></A>
<A NAME="index.66"></A>
</P>
<P>Lorsque vous utilisez une bibliothèque statique, l'éditeur de liens
cherche le code dont votre programme a besoin et en effectue
une copie dans le programme physique généré. Pour les bibliothèques
partagées, c'est le contraire : l'éditeur de liens laisse du code
qui lors du lancement du programme chargera automatiquement la
bibliothèque. Il est évident que ces bibliothèques permettent
d'obtenir un exécutable plus petit; elles permettent également
d'utiliser moins de mémoire et moins de place disque. Linux
effectue par défaut une édition de liens dynamique s'il peut trouver
les bibliothèques de ce type sinon, il effectue une édition de liens
statique. Si vous obtenez des binaires statiques alors que vous les
voulez dynamiques vérifiez que les bibliothèques existent
(<CODE>*.sa</CODE> pour le format a.out, et <CODE>*.so</CODE> pour le format ELF) et
que vous possédez les droits suffisants pour y accéder (lecture).</P>
<P>Sous Linux, les bibliothèques statiques ont pour nom <CODE>libnom.a</CODE>,
alors que les bibliothèques dynamiques sont appelées
<CODE>libnnom.so.x.y.z</CODE> où <CODE>x.y.z</CODE> représente le numéro de
version. Les bibliothèques dynamiques ont souvent des liens logiques qui
pointent dessus, et qui sont très importants. Normalement, les bibliothèques
standards sont livrées sous la double forme dynamique
et statique.</P>
<P>Vous pouvez savoir de quelles bibliothèques dynamiques un programme a besoin
en utilisant la commande <CODE>ldd</CODE> (<EM>List Dynamic Dependencies</EM>)
<BLOCKQUOTE><CODE>
<PRE>
$ ldd /usr/bin/lynx
libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
libc.so.5 => /lib/libc.so.5.2.18
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Cela indique sur mon système que l'outil <CODE>lynx</CODE> (outil WWW)
a besoin des bibliothèques dynamiques <CODE>libc.so.5</CODE> (la bibliothèque C)
et de <CODE>libncurses.so.1</CODE> (nécessaire pour le contrôle du terminal).
Si un programme ne possède pas de dépendances, <CODE>ldd</CODE> indiquera
`<EM>statically linked</EM>' (édition de liens statique).</P>
<P></P>
<A NAME="index.69"></A> <A NAME="index.68"></A> <A NAME="index.67"></A> <H2>6.2 <A NAME="ss6.2"></A> A la recherche des fonctions... ou dans quelle bibliothèque se trouve la fonction <CODE>sin()</CODE> ?') </H2>
<P> <CODE>nm </CODE><EM>nomdebibliothèque</EM> vous donne tous les symboles référencés dans
la bibliothèque. Cela fonctionne que cela soit du code statique ou dynamique.
Supposez que vous vouliez savoir où se trouve définie la fonction
<CODE>tcgetattr()</CODE> :
<BLOCKQUOTE><CODE>
<PRE>
$ nm libncurses.so.1 |grep tcget
U tcgetattr
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>La lettre <CODE>U</CODE> vous indique que c'est indéfini (<EM>Undefined</EM>)
--- cela indique que la bibliothèque ncurses l'utilise mais ne la définit pas.
Vous pouvez également faire :</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ nm libc.so.5 | grep tcget
00010fe8 T __tcgetattr
00010fe8 W tcgetattr
00068718 T tcgetpgrp
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>La lettre `<CODE>W</CODE>' indique que le symbole est défini mais de telle
manière qu'il peut être surchargé par une autre définition de la fonction
dans une autre bibliothèque (W pour <EM>weak</EM> : faible).
Une définition normale est marquée par la lettre `<CODE>T</CODE>'
(comme pour <CODE>tcgetpgrp</CODE>).</P>
<P>
<A NAME="index.70"></A>
</P>
<P>La réponse à la question située dans le titre est
<CODE>libm.(so|a)</CODE>. Toutes les fonctions définies dans le fichier
d'en-tête <CODE><math.h></CODE> sont implémentées dans la
bibliothèque mathématique donc vous devrez effectuer l'édition de liens
grâce à <CODE>-lm</CODE>.</P>
<P></P>
<P></P>
<H2>6.3 <A NAME="ss6.3"></A> Trouver les fichiers</H2>
<P></P>
<P>Supposons que vous ayez le message d'erreur suivant de la part
de l'éditeur de liens :</P>
<P><CODE>ld: Output file requires shared library `libfoo.so.1`</CODE></P>
<P></P>
<P> La stratégie de recherche de fichiers de ld ou de ses copains
diffère de la version utilisée, mais vous pouvez être sûr
que les fichiers situés dans le répertoire <CODE>/usr/lib</CODE>
seront trouvés. Si vous désirez que des fichiers situés à un endroit
différent soient trouvés, il est préférable d'ajouter l'option
<CODE>-L</CODE> à gcc ou ld.</P>
<P></P>
<P> Si cela ne vous aide pas clairement, vérifiez que vous avez le bon
fichier à l'endroit spécifié. Pour un système a.out,
effectuer l'édition de liens avec <CODE>-ltruc</CODE> implique que ld recherche
les bibliothèques <CODE>libtruc.sa</CODE> (bibliothèques partagées), et si elle
n'existe pas, il recherche <CODE>libtruc.a</CODE> (statique). Pour le format
ELF, il cherche <CODE>libtruc.so</CODE> puis <CODE>libtruc.a</CODE>.
<CODE>libtruc.so</CODE> est généralement un lien symbolique vers
<CODE>libtruc.so.x</CODE>.</P>
<P></P>
<H2>6.4 <A NAME="ss6.4"></A> Compiler votre propre bibliothèque</H2>
<H3>Numéro de la version</H3>
<P> Comme tout programme, les bibliothèques ont tendance à avoir quelques
bogues qui sont corrigés au fur et à mesure. De nouvelles
fonctionnalités sont ajoutées et qui peuvent changer l'effet
de celles qui existent ou bien certaines anciennes peuvent êtres supprimées.
Cela peut être un problème pour les programmes qui les utilisent.</P>
<P>Donc, nous introduisons la notion de numéro de version. Nous
répertorions les modifications effectuées dans la bibliothèques
comme étant soit mineures soit majeures. Cela signifie qu'une
modification mineure ne peut pas modifier le fonctionnement d'un
programme (en bref, il continue à fonctionner comme avant). Vous pouvez
identifier le numéro de la version de la bibliothèque en regardant
son nom (en fait c'est un mensonge pour les bibliothèques ELF... mais
continuez à faire comme si !) : <CODE>libtruc.so.1.2</CODE> a pour version
majeure 1 et mineure 2. Le numéro de version mineur peut être
plus ou moins élevé --- la bibliothèque C met un numéro de patch,
ce qui produit un nom tel que <CODE>libc.so.5.2.18</CODE>, et c'est également
courant d'y trouver des lettres ou des blancs soulignés ou tout
autre caractère ASCII affichable.</P>
<P>Une des principales différences entre les formats ELF et a.out
se trouve dans la manière de construire la bibliothèque partagée.
Nous traiterons les bibliothèques partagées en premier car c'est plus
simple.</P>
<P></P>
<A NAME="index.71"></A> <H3>ELF, qu'est-ce que c'est ? </H3>
<P> ELF (<EM>Executable and Linking Format</EM>) est format de binaire
initialement conçu et développé par USL (<EM>UNIX System Laboratories</EM>)
et utilisé dans les systèmes Solaris et System R4. En raison de sa
facilité d'utilisation par rapport à l'ancien format dit a.out qu'utilisait
Linux, les développeurs de GCC et de la bibliothèque C ont décidé
l'année dernière de basculer tout le système sous le format ELF. ELF
est désormais le format binaire standard sous Linux.</P>
<P></P>
<H3>ELF, le retour !</H3>
<P> Ce paragraphe provient du groupe '/news-archives/comp.sys.sun.misc'.</P>
<P>
<BLOCKQUOTE>
ELF (<EM>Executable Linking Format</EM>) est le " nouveau et plus
performant " format de fichier introduit dans SVR4. ELF est beaucoup
plus puissant que le sacro-saint format COFF, dans le sens où il
est extensible. ELF voit un fichier objet comme une longue
liste de sections (plutôt qu'un tableau de taille fixe
d'éléments). Ces sections, à la différence de COFF ne se trouvent
pas à un endroit constant et ne sont pas dans un ordre
particulier, etc. Les utilisateurs peuvent ajouter une nouvelle
section à ces fichiers objets s'il désirent y mettre de nouvelles
données. ELS possède un format de débogage plus puissant
appelé DWARF (<EM>Debugging With Attribute Record Format</EM>) -
par encore entièrement géré par Linux (mais on y travaille !).
Une liste chaînée de " DWARF DIEs " (ou <EM>Debugging Information
Entries</EM> - NdT... le lecteur aura sûrement noté le jeu de mot
assez noir : dwarf = nain; dies = morts) forment la section <EM>.debug</EM>
dans ELF. Au lieu d'avoir une liste de petits enregistrements d'information
de taille fixes, les DWARF DIEs contiennent chacun une longue liste
complexe d'attributs et sont écrits sous la forme d'un arbre de données.
Les DIEs peuvent contenir une plus grande quantité d'information
que la section <EM>.debug</EM> du format COFF ne le pouvait (un peu comme
les graphes d'héritages du C++).
</BLOCKQUOTE>
<BLOCKQUOTE>
Les fichiers ELF sont accessibles grâce à la bibliothèque d'accès
de SVR4 (Solaris 2.0 peut-être ?), qui fournit une interface simple
et rapide aux parties les plus complexes d'ELF. Une des aubaines que
permet la bibliothèque d'accès ELF est que vous n'avez jamais besoin
de connaître les méandres du format ELF. Pour accéder à un fichier Unix,
on utilise un Elf *, retourné par un appel à elf_open(). Ensuite,
vous effectuez des appels à elf_foobar() pour obtenir les différents
composants au lieu d'avoir à triturer le fichier physique
sur le disque (chose que beaucoup d'utilisateurs de COFF ont fait...).
</BLOCKQUOTE>
</P>
<P>Les arguments pour ou contre ELF, et les problèmes liés
à la mise à jour d'un système a.out vers un système ELF sont décrits
dans le ELF-HOWTO et je ne veux pas effectuer de copier coller ici
(NdT: ce HowTo est également traduit en français).
Ce HowTo se trouve au même endroit que les autres.</P>
<P></P>
<H3>Les bibliothèque partagées ELF</H3>
<P> Pour construire <CODE>libtruc.so</CODE> comme une bibliothèque dynamique,
il suffit de suivre les étapes suivantes :</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ gcc -fPIC -c *.c
$ gcc -shared -Wl,-soname,libtruc.so.1 -o libtruc.so.1.0 *.o
$ ln -s libtruc.so.1.0 libtruc.so.1
$ ln -s libtruc.so.1 libtruc.so
$ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ; export LD_LIBRARY_PATH
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Cela va générer une bibliothèque partagée appelée <CODE>libtruc.so.1.0</CODE>,
les liens appropriés pour ld (<CODE>libtruc.so</CODE>) et
le chargeur dynamique (<CODE>libtruc.so.1</CODE>) pour le trouver.
Pour tester, nous ajoutons le répertoire actuel à la
variable d'environnement <CODE>LD_LIBRARY_PATH</CODE>.</P>
<P>
<A NAME="index.72"></A>
</P>
<P>Lorsque vous êtes satisfait et que la bibliothèque fonctionne, vous
n'avez plus qu'à la déplacer dans le répertoire par exemple,
<CODE>/usr/local/lib</CODE>, et de recréer les liens appropriés. Le lien
de <CODE>libtruc.so.1</CODE> sur <CODE>libtruc.so.1.0</CODE> est enregistré par
<CODE>ldconfig</CODE>, qui sur bon nombre de systèmes est lancé lors
du processus d'amorçage. Le lien <CODE>libfoo.so</CODE> doit être mis à jour
à la main. Si vous faites attention lors de la mise à jour de la
bibliothèque la chose la plus simple à réaliser est de créer le lien
<CODE>libfoo.so -> libfoo.so.1</CODE>, pour que ldconfig conserve les liens
actuels. Si vous ne faites pas cela, vous aurez des problèmes plus
tard. Ne me dites pas que l'on ne vous a pas prévenu !</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ /bin/su
# cp libtruc.so.1.0 /usr/local/lib
# /sbin/ldconfig
# ( cd /usr/local/lib ; ln -s libtruc.so.1 libtruc.so )
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P></P>
<A NAME="index.74"></A> <A NAME="index.73"></A> <H3>Les numéros de version, les noms et les liens </H3>
<P> Chaque bibliothèque possède un nom propre (<EM>soname</EM>).
Lorsque l'éditeur de liens en trouve un qui correspond à un nom
cherché, il enregistre le nom de la bibliothèque dans le code binaire
au lieu d'y mettre le nom du fichier de la bibliothèque. Lors de
l'exécution, le chargeur dynamique va alors chercher un fichier ayant
pour nom le nom propre de la bibliothèque, et pas le nom du fichier
de la bibliothèque. Par exemple, une bibliothèque ayant pour nom
<CODE>libtruc.so</CODE> peut avoir comme nom propre <CODE>libbar.so</CODE>, et tous
les programmes liés avec vont alors chercher <CODE>libbar.so</CODE>
lors de leur exécution.</P>
<P></P>
<P>Cela semble être une nuance un peu pointilleuse mais c'est la clef
de la compréhension de la coexistence de plusieurs versions
différentes de la même bibliothèque sur le même système.
On a pour habitude sous Linux d'appeler une bibliothèque
<CODE>libtruc.so.1.2</CODE> par exemple, et de lui donner comme
nom propre <CODE>libtruc.so.1</CODE>. Si cette bibliothèque est rajoutée
dans un répertoire standard (par exemple dans <CODE>/usr/lib</CODE>),
le programme <CODE>ldconfig</CODE> va créer un lien symbolique
entre <CODE>libtruc.so.1 -> libtruc.so.1.2</CODE> pour que l'image
appropriée soit trouvée lors de l'exécution. Vous aurez également besoin
d'un lien symbolique <CODE>libtruc.so -> libtruc.so.1</CODE> pour que ld
trouve le nom propre lors de l'édition de liens.</P>
<P> Donc, lorsque vous corrigez des erreurs dans la bibliothèque ou
bien lorsque vous ajoutez de nouvelles fonctions (en fait, pour
toute modification qui n'affecte pas l'exécution des programmes déjà
existants), vous reconstruisez la bibliothèque, conservez le nom propre
tel qu'il était et changez le nom du fichier. Lorsque vous effectuez des
modifications que peuvent modifier le déroulement des programmes
existants, vous pouvez tout simplement incrémenter le nombre situé
dans le nom propre --- dans ce cas, appelez la nouvelle version de la
bibliothèque <CODE>libtruc.so.2.0</CODE>, et donnez-lui comme nom propre
<CODE>libtruc.so.2</CODE>. Maintenant, faites pointer le lien de
<CODE>libfoo.so</CODE> vers la nouvelle version et tout est bien dans
le meilleur des mondes !</P>
<P>Il est utile de remarquer que vous n'êtes pas obligé de nommer
les bibliothèques de cette manière, mais c'est une bonne convention.
Elf vous donne une certaine liberté pour nommer des bibliothèques
tant et si bien que cela peut perturber certains utilisateurs, mais cela
ne veut pas dire que vous êtes obligé de le faire.</P>
<P>Résumé : supposons que choisissiez d'adopter la méthode traditionnelle
avec les mises à jour majeures qui peuvent ne pas être compatibles
avec les versions précédentes et les mises à jour mineures qui ne posent
pas ce problème. Il suffit de créer la bibliothèque de cette manière :</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
gcc -shared -Wl,-soname,libtruc.so.majeur -o libtruc.so.majeur.mineur
</PRE>
</CODE></BLOCKQUOTE>
et tout devrait être parfait !</P>
<P></P>
<H3>a.out. Le bon vieux format </H3>
<P> La facilité de construire des bibliothèque partagées est la
raison principale de passer à ELF. Ceci dit, il est toujours possible
de créer des bibliothèques dynamiques au format a.out. Récupérez
le fichier archive
<A HREF="ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz">ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz</A>
et lisez les 20 pages de documentation que vous trouverez dedans
après l'avoir désarchivé. Je n'aime pas avoir l'air d'être aussi
partisan, mais il est clair que je n'ai jamais aimé ce format :-).</P>
<P></P>
<A NAME="index.76"></A> <A NAME="index.75"></A> <H3>ZMAGIC contre QMAGIC </H3>
<P> QMAGIC est le format des exécutables qui ressemble un peu aux vieux
binaires a.out (également connu comme ZMAGIC), mais qui laisse
la première page libre. Cela permet plus facilement de récupérer
les adresses non affectées (comme NULL) dans l'intervalle
0-4096 (NdT : Linux utilise des pages de 4Ko).</P>
<P>Les éditeurs de liens désuets ne gèrent que le format ZMAGIC, ceux
un peu moins rustiques gèrent les deux, et les plus récents uniquement
le QMAGIC. Cela importe peu car le noyau gère les deux types.</P>
<P>La commande <CODE>file</CODE> est capable d'identifier si un programme est
de type QMAGIC.</P>
<P></P>
<H3>Gestion des fichiers</H3>
<P>Une bibliothèque dynamique a.out (DLL) est composée de
deux fichiers et d'un lien symbolique. Supposons que l'on
utilise la bibliothèque <EM>truc</EM>, les fichiers seraient
les suivants : <CODE>libtruc.sa</CODE> et <CODE>libtruc.so.1.2</CODE>; et le
lien symbolique aurait pour nom <CODE>libtruc.so.1</CODE> et pointerait
sur le dernier des fichiers. Mais à quoi servent-ils ?</P>
<P>Lors de la compilation, <CODE>ld</CODE> cherche <CODE>libtruc.sa</CODE>.
C'est le fichier de description de la bibliothèque : il contient
toutes les données exportées et les pointeurs vers les fonctions
nécessaires pour l'édition de liens.</P>
<P>Lors de l'exécution, le chargeur dynamique cherche <CODE>libtruc.so.1</CODE>.
C'est un lien symbolique plutôt qu'un réel fichier pour que les
bibliothèques puissent être mise à jour sans avoir à casser les
applications qui utilisent la bibliothèque. Après la mise à jour,
disons que l'on est passé à la version <CODE>libfoo.so.1.3</CODE>,
le lancement de ldconfig va positionner le lien. Comme
cette opération est atomique, aucune application fonctionnant
n'aura de problème.</P>
<P>Les bibliothèques DLL (Je sais que c'est une tautologie... mais pardon !)
semblent être très souvent plus importantes que leur équivalent
statique. En fait, c'est qu'elles réservent de la place pour les
extensions ultérieures sous la simple forme de trous qui sont
fait de telle manière qu'ils n'occupent pas de place disque (NdT :
un peu comme les fichiers <CODE>core</CODE>). Toutefois, un
simple appel à <CODE>cp</CODE> ou à <CODE>makehole</CODE> les remplira...
Vous pouvez effectuer une opération de <CODE>strip</CODE> après la construction
de la bibliothèque, comme les adresses sont à des endroits fixes.
<B>Ne faites pas la même opération avec les bibliothèques ELF !</B></P>
<P></P>
<H3>" libc-lite " ?</H3>
<P> Une " libc-lite " (contraction de <EM>libc</EM> et <EM>little</EM>)
est une version épurée et réduite de la bibliothèque
libc construite de telle manière qu'elle puisse tenir sur
une disquette avec un certain nombre d'outil Unix.
Elle n'inclut pas curses, dbm, termcap, ...
Si votre <CODE>/lib/libc.so.4</CODE> est liée avec une bibliothèque de ce genre
il est très fortement conseillé de la remplacer avec une version complète.</P>
<P></P>
<H3>Edition de liens : problème courants </H3>
<P> Envoyez-les moi ! </P>
<P>
<DL>
<P></P>
<DT><B> Des programmes statiques lorsque vous les voulez
partagés</B><DD><P>
<A NAME="index.77"></A>
<A NAME="index.78"></A>
</P>
<P>Vérifiez que vous avez les bons liens pour que <CODE>ld</CODE> puisse
trouver les bibliothèques partagées. Pour ELF cela veut dire que
<CODE>libtruc.so</CODE> est un lien symbolique sur son image,
pour a.out un fichier <CODE>libtruc.sa</CODE>. Beaucoup de personnes
ont eu ce problème après être passés des outils ELF 2.5 à 2.6
(<CODE>binutils</CODE>) --- la dernière version effectue une recherche
plus intelligente pour les bibliothèques dynamiques et donc ils
n'avaient pas créé tous les liens symboliques nécessaires.
Cette caractéristique avait été supprimée pour des raisons de compatibilité
avec d'autres architectures et parce qu'assez souvent cela ne marchait
pas bien. En bref, cela posait plus de problèmes qu'autre chose.</P>
<P></P>
<DT><B> Le programme `mkimage' n'arrive pas à trouver libgcc</B><DD><P>
<A NAME="index.79"></A>
</P>
<P>Comme <CODE>libc.so.4.5.x</CODE> et suivantes, libgcc n'est pas une
bibliothèque partagée. Vous devez remplacer les `<CODE>-lgcc</CODE>'
sur la ligne de commande par
<CODE>`gcc -print-libgcc-file-name`</CODE> (entre quotes)</P>
<P>Egalement, détruisez tous les fichiers situés dans <CODE>/usr/lib/libgcc*</CODE>.
C'est important.</P>
<P></P>
<DT><B> Le message <CODE>__NEEDS_SHRLIB_libc_4 multiply defined</CODE></B><DD><P>Sont une conséquence du même problème.</P>
<P></P>
<DT><B> Le message ``Assertion failure'' apparaît lorsque vous reconstruisez une
DLL</B><DD><P>Ce message énigmatique signifie qu'un élément de votre table <EM>jump</EM>
a dépassé la table car trop peu de place était réservée dans le fichier
<CODE>jump.vars</CODE> file. Vous pouvez trouver le(s) coupable(s) en lançant
la commande <CODE>getsize</CODE> fournie dans le paquetage tools-2.17.tar.gz.
La seule solution est de passer à une nouvelle version majeure,
même si elle sera incompatible avec les précédentes.</P>
<P></P>
<DT><B> <CODE>ld: output file needs shared library libc.so.4</CODE> </B><DD><P>Cela arrive lorsque vous effectuez l'édition de liens avec des bibliothèques
différentes de la libc (comme les bibliothèques X) et que vous utilisez
l'option <CODE>-g</CODE> sans utiliser l'option <CODE>-static</CODE>.</P>
<P>Les fichiers <CODE>.sa</CODE> pour les bibliothèques dynamiques ont un symbole
non résolu <CODE>_NEEDS_SHRLIB_libc_4</CODE> qui est défini dans
<CODE>libc.sa</CODE>. Or, lorsque vous utilisez <CODE>-g</CODE> vous faites l'édition
de liens avec <CODE>libg.a</CODE> ou <CODE>libc.a</CODE> et donc ce symbole n'est jamais
défini.</P>
<P>Donc, pour résoudre le problème, ajoutez l'option <CODE>-static</CODE>
lorsque vous compilez avec l'option <CODE>-g</CODE>, ou n'utilisez pas
<CODE>-g</CODE> lors de l'édition de liens !</P>
</DL>
</P>
<P></P>
<P></P>
<HR>
<P>
Chapitre <A HREF="GCC-HOWTO-7.html">suivant</A>,
Chapitre <A HREF="GCC-HOWTO-5.html">Précédent</A>
<P>
Table des matières de <A HREF="GCC-HOWTO.html#toc6">ce chapitre</A>,
<A HREF="GCC-HOWTO.html#toc">Table des matières</A> générale</P>
<P>
<A HREF="GCC-HOWTO.html">Début</A> du document,
<A HREF="#0"> Début de ce chapitre</A></P>
</BODY>
</HTML>
