  GCC HOWTO pour Linux
  par Daniel Barlow <dan@detached.demon.co.uk>
  v1.17, 28 fevrier 1996

  (Adaptation  francaise  par  Eric  Dumas  <dumas@freenix.fr>,  8 Avril
  1996).  Ce document presente la maniere de configurer  le  compilateur
  GNU  C  et  les bibliotheques de developpement sous Linux. Il donne un
  apercu de la compilation, de l'edition de liens, de l'execution et  du
  debogage  de programmes sous Linux. Bon nombre de passages de ce docu-
  ment sont empruntes a la FAQ GCC redigee par  Mitch  D'Souza's  et  au
  HowTo  ELF.  Ceci est la premiere version publique (en depit du numero
  de version : en fait, ca vient de RCS). N'hesitez  pas  a  me  joindre
  pour toute remarque.

  11..  PPrreelliimmiinnaaiirreess

  11..11..

  EELLFF eett aa..oouutt

  Le   developpement  de  Linux  est  actuellement  dans  une  phase  de
  transition.  En resume, il existe deux formats de binaires  que  Linux
  reconnait  et execute, et cela depend de la maniere dont votre systeme
  est configure : vous pouvez avoir les deux, l'un ou l'autre. En lisant
  ce  document,  vous  pourrez  savoir  quels binaires votre systeme est
  capable de gerer.

  Comment le savoir ? Utilisez  la  commande  file  (par  exemple,  file
  /bin/bash).  Pour  un  programme  ELF, cette commande va vous repondre
  quelque chose dans lequel se trouve le  mot  ELF.  Dans  le  cas  d'un
  programme  en a.out, il vous indiquera quelque chose comme Linux/i386.

  Les differences entre ELF et a.out sont detaillees plus tard  dans  ce
  document.  ELF  est  le nouveau format et il est considere comme etant
  meilleur.

  11..22..

  DDuu ccoottee dduu ccooppyyrriigghhtt

  Le copyright et autres informations legales peuvent etre trouves a  la
  _f_i_n  de ce document, avec les avertissements conventionnels concernant
  la maniere de poser des questions sur Usenet  pour  eviter  d'avoir  a
  reveler  votre ignorance du langage C en annoncant des bogues qui n'en
  sont pas, etc.

  11..33..  TTyyppooggrraapphhiiee

  Si vous lisez ce document au format Postscript,  dvi,  ou  HTML,  vous
  pouvez  voir quelques difference entre les styles d'ecriture alors que
  les gens qui consultent ce document au format  texte  pur  ne  verront
  aucune  difference.  En  particulier, les noms de fichiers, le nom des
  commandes, les messages donnes par les programmes et les codes sources
  seront  ecrits avec le style suivant : style d'ecriture, alors que les
  noms de variables entre autres choses seront en _i_t_a_l_i_q_u_e.

  Vous aurez egalement un index. Avec les formats dvi ou postscript, les
  chiffres  dans  l'index  correspondent  au numeros de paragraphes.  Au
  format HTML, il s'agit d'une numerotation sequentielle pour  que  vous
  puissiez  cliquer  dessus.  Avec  le  format texte, ce ne sont que des
  nombres. Il vous est donc conseille de prendre un autre format que  le
  format texte !

  L'interpreteur  de  commande (_s_h_e_l_l) utilise dans les exemples sera la
  Bourne shell (plutot que le  C-Shell).  Les  utilisateurs  du  C-Shell
  utiliseront plutot :

       % setenv soif JD

  la ou j'ai ecrit

       $ soif=JD; export soif

  Si  l'invite  (_p_r_o_m_p_t dans la langue de Shakespeare) est  # plutot que
  $, la commande ne fonctionnera que si elle  est  executee  au  nom  de
  Root.  Bien  sur,  je  decline  toute responsabilite de ce qui peut se
  produire sur votre systeme lors de l'execution de ces exemples.  Bonne
  chance :-)

  22..  OOuu rreeccuuppeerreerr ddee llaa ddooccuummeennttaattiioonn eett lleess pprrooggrraammmmeess ??

  22..11..  CCee ddooccuummeenntt

  Ce  document  fait  partie de la serie des HOWTO pour Linux, et il est
  donc disponible ainsi que ces collegues  dans  les  repertoires  HowTo
  pour Linux, comme sur  <http://sunsite.unc.edu/pub/linux/docs/HOWTO/>.
  La    version    HTML    peut    egalement    etre    consultee    sur
  <http://ftp.linux.org.uk/~barlow/howto/gcc-howto.html>.

  Note  du  traducteur  :  vous pouvez obtenir tous les HowTos en langue
  anglaise  et  francaise  sur   ftp.ibp.fr:/pub/linux.   Les   versions
  francaises se trouvent dans le repertoire /pub/linux/french/HOWTO.

  22..22..

  AAuuttrreess ddooccuummeennttaattiioonn

  La  documentation officielle pour gcc se trouve dans les sources de la
  distribution (voir plus bas) sous la forme de fichiers texinfo  et  de
  fichiers  .info.  Si  vous possedez une connexion rapide, un CD-ROM ou
  une certaine patience, vous pouvez  desarchiver  la  documentation  et
  l'installer dans le repertoire /usr/info.  Sinon, vous pouvez toujours
  les                 trouver                 sur                 tsx-11
  <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>,  mais  ce  n'est  pas
  necessairement toujours la derniere version.

  Il existe deux sources de documentation pour la libc. La libc GNU  est
  fournie avec des fichiers info qui decrivent assez precisement la libc
  Linux sauf pour la partie des entrees-sorties.  Vous pouvez  egalement
  trouver   sur   sunsite   <ftp://sunsite.unc.edu/pub/Linux/docs/>  des
  documents ecrits pour Linux ainsi  que  la  description  de  certaines
  appels systemes (section 2) et certaines fonctions de la libc (section
  3).
  Note du traducteur : un bemol concernant cette partie... La libc Linux
  n'est  pas  GNU  et  tend  a etre relativement differente sur certains
  points.

  22..33..  GGCCCC

  Il existe deux types de reponses

  (a) La distribution officielle de GCC pour Linux  peut  toujours  etre
  recuperee   sous   la   forme   de   binaires   (deja   compilee)  sur
  <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>.   Vous   pouvez    la
  trouver           sur           le           miroir           francais
  <ftp://ftp.ibp.fr:/pub/linux/packages/GCC/>.  A l'heure ou j'ecris ces
  lignes, la derniere version est gcc 2.7.2 (gcc-2.7.2.bin.tar.gz).

  (b)  La  derniere  distribution des sources de GCC de la _F_r_e_e _S_o_f_t_w_a_r_e
  _F_o_u_n_d_a_t_i_o_n      peut-etre      recuperee      sur      prep.ai.mit.edu
  <ftp://prep.ai.mit.edu/pub/gnu/>             ou             ftp.ibp.fr
  <ftp://ftp.ibp.fr/pub/gnu/>.  Ce n'est pas toujours  la  meme  version
  que  celle presentee ci-dessus.  Les mainteneurs de GCC pour Linux ont
  rendu la compilation de GCC  plus  facile  grace  a  l'utilisation  du
  script   configure   qui   effectue  la  configuration  d'une  maniere
  automatique.              Regardez             dans             tsx-11
  <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>      ou     ftp.ibp.fr
  <ftp://ftp.ibp.fr:/pub/linux/packages/GCC/> pour recuperer d'eventuels
  patches.

  Quelle que soit la complexite de votre programme, vous aurez egalement
  besoin de la _l_i_b_c.

  22..44..

  LLeess ffiicchhiieerrss dd''eenn--tteettee eett llaa bbiibblliiootthheeqquuee CC

  Ce que vous allez trouver dans ce paragraphe depend

  +o  de votre systeme (ELF ou a.out) ;

  +o  du type de binaire que vous desirez generer.

     Si vous etes en train de mettre a jour votre libc 4 en libc 5, vous
     devriez consulter le ELF HowTo qui se trouve au meme endroit que ce
     document.

  Les       libc        sont        disponibles        sur        tsx-11
  <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>      ou     ftp.ibp.fr
  <ftp://ftp.ibp.fr:/pub/linux/packages/GCC/>. Voici une description des
  fichiers situes dans ce repertoire :

     lliibbcc--55..22..1188..bbiinn..ttaarr..ggzz
        ---  bibliotheques dynamiques et statiques ELF plus les fichiers
        d'en-tete  pour   la   bibliotheque   C   et   la   bibliotheque
        mathematique.

     lliibbcc--55..22..1188..ttaarr..ggzz
        ---  Code  source  pour  la  bibliotheque ci-dessus.  Vous aurez
        egalement besoin du paquetage  .bin.  pour  avoir  les  fichiers
        d'en-tete.  Si  vous  hesitez  entre  compiler la bibliotheque C
        vous-meme et utiliser les binaires, la bonne reponse est dans la
        majorite des cas est d'utiliser les binaires. Toutefois, si vous
        desirer utiliser NYS (NdT : NYS != NIS)  ou  bien  les  mots  de
        passe _s_h_a_d_o_w, vous devrez recompiler la libc par vous-meme.

     lliibbcc--44..77..55..bbiinn..ttaarr..ggzz
        ---  bibliotheques dynamiques et statiques a.out pour la version
        4.7.5 de la libc.  Cette bibliotheque a ete concue pour  pouvoir
        coexister  avec le paquetage de la libc 5 decrit ci-dessus, mais
        c'est  uniquement  necessaire  si  vous  desirez   utiliser   ou
        developper des programmes au format a.out.

  22..55..

  OOuuttiillss aassssoocciieess ((aass,, lldd,, aarr,, ssttrriinnggss,, eettcc..))

  Ces  outils  se  trouvent  comme  les bibliotheques dans le repertoire
  tsx-11 <ftp://tsx-11.mit.edu:/pub/linux/packages/GCC/>, et  ftp.ibp.fr
  <ftp://ftp.ibp.fr:/pub/linux/packages/GCC/>.   La version actuelle est
  binutils-2.6.0.2.bin.tar.gz.

  Il est utile de remarquer que ces outils  ne  sont  disponibles  qu'au
  format  ELF, que la libc actuelle est ELF et que la libc a.out ne pose
  pas de probleme  lorsqu'elle  est  utilisee  avec  la  libc  ELF.   Le
  developpement de la libc est relativement rapide et a moins que n'ayez
  de bonnes raisons pour utiliser le format a.out, vous etes  encourages
  a suivre le mouvement.

  33..  IInnssttaallllaattiioonn eett ccoonnffiigguurraattiioonn ddee GGCCCC

  33..11..

  LLeess vveerrssiioonnss ddee GGCCCC

  Vous  pouvez  savoir quelle est la version de GCC que vous possedez en
  tapant gcc -v lors de l'invite. C'est egalement  une  bonne  technique
  pour savoir si votre configuration est ELF ou a.out.  Sur mon systeme,
  cela donne ceci :

       $ gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-zorglub-linux/2.7.2/specs
       gcc version 2.7.2

  Les mots-clefs a remarquer

  +o  i486.  Cela vous indique que la version de gcc que vous utilisez  a
     ete compilee pour etre utilisee sur un processeur 486 --- mais vous
     pouvez avoir un autre processeur comme un 386 ou un Pentium  (586).
     Tous   ces  processeurs  peuvent  executer  le  code  compile  avec
     n'importe quel processeur. La seule difference reside dans le  fait
     que  le  code  486 rajoute  un peu de code a certains endroits pour
     aller plus vite sur un 486.  Cela  n'a  pas  d'effet  nefaste  cote
     performance  sur  un 386 mais cela rend les executables un peu plus
     importants.
  +o  zorglub.   Ce  n'est  pas  reellement  important,  et   il   s'agit
     generalement  d'un commentaire (comme slackware or debian) ou meme,
     cela peut-etre vide (lorsque vous  avez  comme  nom  de  repertoire
     i486-linux).   Si  vous  construisez  votre propre gcc, vous pouvez
     fixer ce parametre selon vos desirs, comme je l'ai fait.  :-)

  +o  linux.  Cela peut etre a la place linuxelf ou linuxaout et en fait,
     la signification varie en fonction de la version que vous possedez.

  +o  linux signifie ELF si la version est 2.7.0  ou  superieure,  sinon,
     c'est du a.out.

  +o  linuxaout signifie a.out.  Cela a ete introduit comme cible lorsque
     le format des binaires a change  de  a.out  vers  ELF  dans  LLiinnuuxx.
     Normalement,  vous  ne verrez plus de linuxaout avec une version de
     gcc superieure a 2.7.0.

  +o  linuxelf est depasse. Il s'agit generalement de gcc  version  2.6.3
     configure pour generer des executables ELF. Notez que gcc 2.6.3 est
     connu pour generer de nombreuses erreurs lorsqu'il produit du  code
     ELF --- une mise a jour est tres fortement recommandee.

  +o  2.7.2 est le numero de la version de GCC.

  Donc,  en  resume,  nous  possedons  gcc 2.7.2 qui genere du code ELF.
  _Q_u_e_l_l_e _s_u_r_p_r_i_s_e (NdT: En francais dans le texte) !

  33..22..  AA qquueell eennddrrooiitt ss''iinnssttaallllee GGCCCC ??

  Si vous avez installe gcc sans regarder, ou bien si vous l'avez  eu  a
  partir  d'une distribution, vous pouvez avoir envie de savoir ou il se
  trouve dans votre arborescence. Les mots clefs permettant cela sont

  +o  /usr/lib/gcc-lib/_m_a_c_h_i_n_e_-_c_i_b_l_e/_v_e_r_s_i_o_n/ (et  ses  sous-repertoires)
     est  generalement  l'endroit  ou  se  trouve  le  plus  souvent  le
     compilateur.   Ceci  inclut  les  executables  qui   realisent   la
     compilation  ainsi que certaines bibliotheques et quelques fichiers
     d'en-tete.

  +o  /usr/bin/gcc est le lanceur du compilateur ---  c'est  en  fait  le
     programme  que  vous  lancez.   Il peut etre utilise avec plusieurs
     versions  de  gcc  lorsque  vous  possedez  plusieurs   repertoires
     installes  (voir  plus  bas).  Pour  trouver  la version par defaut
     utilisee, lancez gcc -v.  Pour  forcer  l'utilisation  d'une  autre
     version, lancez gcc -V _v_e_r_s_i_o_n. Par exemple,

       # gcc -v
       Reading specs from /usr/lib/gcc-lib/i486-zorglub-linux/2.7.2/specs
       gcc version 2.7.2
       # gcc -V 2.6.3 -v
       Reading specs from /usr/lib/gcc-lib/i486-zorglub-linux/2.6.3/specs
       gcc driver version 2.7.2 executing gcc version 2.6.3

  +o  /usr/_m_a_c_h_i_n_e_-_c_i_b_l_e/(bin|lib|include)/.    Si   vous  avez  installe
     plusieurs cibles possibles (par exemple a.out et elf,  ou  bien  un
     compilateur  croise, les bibliotheques, les binutils (as, ld, etc.)
     et les fichiers d'en-tete  pour les cibles differente de celle  par
     defaut  peuvent  etre  trouves  a cet endroit.  Meme si vous n'avez
     qu'une seule version  de  gcc  installee,  vous  devriez  toutefois
     trouver  a  cet  endroit un certain nombre de fichiers. Si ce n'est
     pas la cas, regardez dans /usr/(bin|lib|include).

  +o  /lib/,  /usr/lib  et  autres  sont   les   repertoires   pour   les
     bibliotheques  pour le systeme initial. Vous aurez egalement besoin
     du programme  /lib/cpp  pour  un  grand  nombre  d'applications  (X
     l'utilise   beaucoup)   ---   soit  vous  le  copiez  a  partir  de
     /usr/lib/gcc-lib/_m_a_c_h_i_n_e_-_c_i_b_l_e/_v_e_r_s_i_o_n/, soit vous faites   pointer
     un lien symbolique dessus.

  33..33..

  OOuu ssee ttrroouuvveenntt lleess ffiicchhiieerrss dd''eenn--tteettee ??

  Si l'on excepte les fichier fichiers d'en-tete que vous installez dans
  le repertoire /usr/local/include,  il y  a  en  fait  trois  types  de
  fichiers d'en-tete :

  +o  La   grande   majorite  des  fichiers  situes  dans  le  repertoire
     /usr/include/ et dans ses sous-repertoires proviennent du paquetage
     de la libc dont s'occupe H.J. Lu. Je dis bien la "grande  majorite"
     car  vous  pouvez  avoir  egalement  certains  fichiers   provenant
     d'autres  sources  (par  exemple  des bibliotheques curses et dbm),
     ceci est d'autant plus vrai si vous possedez une distribution de la
     libc  recente  (ou  les  bibliotheques  curses  et  dbm ne sont pas
     integrees).

  +o  Les repertoires /usr/include/linux et  /usr/include/asm  (pour  les
     fichiers   <linux/*.h>   et   <asm/*.h>)  doivent  etre  des  liens
     symboliques   vers   les   repertoires    linux/include/linux    et
     linux/include/asm  situes  dans  les  sources du noyau. Vous devrez
     installer ces sources si vous  desirez  pouvoir  developper  :  ces
     sources ne sont pas utilises uniquement pour compiler le noyau.

     Il est probable que vous ayez besoin de lancer la commande suivante
     make config dans le repertoire des sources du noyau apres les avoir
     installes.  Beaucoup  de  fichiers  ont besoin du fichier d'en-tete
     <linux/autoconf.h> qui n'existe pas sans cette commande. Il  est  a
     noter  que  dans certaines versions du noyau, le repertoire asm est
     en fait un lien symbolique qui n'est cree  qu'avec  l'execution  de
     make config.

     Donc,  si  vous  installez  les sources du noyau dans le repertoire
     /usr/src/linux, il suffit de faire :

       $ cd /usr/src/linux
       $ su
       # make config
       [repondez aux questions. A moins que vous ne recompiliez votre
       noyau, les reponses importent peu]
       # cd /usr/include
       # ln -s ../src/linux/include/linux .
       # ln -s ../src/linux/include/asm .

  +o  Les  fichiers  tels   que   <float.h>,   <limits.h>,   <varargs.h>,
     <stdarg.h>  et  <stddef.h>  changent  en  fonction de la version du
     compilateur,  et  peuvent   etre   trouves   dans   le   repertoire
     /usr/lib/gcc-lib/i486-box-linux/2.7.2/include/   pour   la  version
     2.7.2.

  33..44..  CCoonnssttrruuiirree uunn ccoommppiillaatteeuurr ccrrooiissee

  33..44..11..  LLiinnuuxx ccoommmmee ppllaattee--ffoorrmmee ddee ddeessttiinnaattiioonn

  Nous  supposons  que  vous  avez  recupere  les  sources  de  gcc,  et
  normalement, il vous suffit de suivre les instructions donnees dans le
  fichier INSTALL situe dans les sources de gcc. Ensuite, il  suffit  de
  lancer  configure  --target=i486-linux  --host=XXX  sur une plateforme
  XXX, puit un make devrait compiler gcc correctement. Il  est  a  noter
  que  vous  aurez besoin des fichiers d'en-tete de Linux, ainsi que les
  sources de l'assembleur et du l'editeur  de  liens  croises  que  vous
  pouvez  trouver sur  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/> ou
  <ftp://ftp.ibp.fr/pub/linux/GCC/>.

  33..44..22..  LLiinnuuxx ccoommmmee ppllaattee--ffoorrmmee oorriiggiinnee eett MMSSDDOOSS ccoommmmee ddeessttiinnaattiioonn

  Arggg.  Apparemment, cela est possible en utilisant le paquetage " emx
  "       ou       l'extension       "       go       ".        Regardez
  <ftp://sunsite.unc.edu/pub/Linux/devel/msdos>         pour        plus
  d'informations.

  Je n'ai pas teste cela et je ne pense pas le faire !

  44..  PPoorrttaaggee eett ccoommppiillaattiioonn

  44..11..

  SSyymmbboolleess ddeeffiinniiss aauuttoommaattiiqquueemmeenntt

  Vous pouvez trouver  quels  symboles  votre  version  de  gcc  definit
  automatiquement  en  le  lancant  avec  l'option -v.  Par exemple cela
  donne ca chez moi :

       $ echo 'main(){printf("Bonjour !\n");}' | gcc -E -v -
       Reading specs from /usr/lib/gcc-lib/i486-box-linux/2.7.2/specs
       gcc version 2.7.2
        /usr/lib/gcc-lib/i486-box-linux/2.7.2/cpp -lang-c -v -undef
       -D__GNUC__=2 -D__GNUC_MINOR__=7 -D__ELF__ -Dunix -Di386 -Dlinux
       -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386
       -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386)
       -Amachine(i386) -D__i486__ -

  Si vous ecrivez du code qui utilise des  specificites  Linux,  il  est
  souhaitable d'implementer le code non portable de la maniere suivante

       #ifdef __linux__
       /* ... code linux ... */
       #endif /* linux */

  Utilisez __linux__ pour cela, et _p_a_s linux.  Bien que cette macro soit
  definie, ce n'est pas une specification POSIX.

  44..22..  OOppttiioonnss ddee ccoommppiillaattiioonn

  La documentation des options de compilation se trouve dans  les  pages
  _i_n_f_o  de  gcc  (sous  Emacs, utilisez C-h i puis selectionnez l'option
  `gcc').   Votre  distribution  peut   ne   pas   avoir   installe   la
  documentation  ou bien vous pouvez en avoir une ancienne. Dans ce cas,
  la meilleure chose a faire est de recuperer les sources de gcc  depuis
  <ftp://prep.ai.mit.edu/pub/gnu>  ou l'un des ses nombreux miroirs dont
  <ftp://ftp.ibp.fr/pub/gnu>.

  La page de manuel gcc (gcc.1) est en principe, completement  depassee.
  Cela vous met en garde si vous desirez la consulter.

  44..22..11..

  OOppttiioonnss ddee ccoommppiillaattiioonn

  gcc peut realiser un certain nombre d'optimisations sur le code genere
  en ajoutant l'option -O_n a la ligne de commandes, ou _n est un chiffre.
  La  valeur de _n, et son effet exact, depend de la version de gcc, mais
  s'echelonne normalement entre 0 (aucune optimisation) et 2 (un certain
  nombre) ou 3 (toutes les optimisations possibles).

  En  interne,  gcc  interprete  les  options telles que -f et -m.  Vous
  pouvez voir exactement ce qu'effectue le niveau specifie dans l'option
  -O  en  lancant  gcc avec l'option -v et l'option (non documentee) -Q.
  Par exemple, l'option -O2, effectue les operations  suivantes  sur  ma
  machine :

       enabled: -fdefer-pop -fcse-follow-jumps -fcse-skip-blocks
       -fexpensive-optimizations
                -fthread-jumps -fpeephole -fforce-mem -ffunction-cse -finline
                -fcaller-saves -fpcc-struct-return -frerun-cse-after-loop
                -fcommon -fgnu-linker -m80387 -mhard-float -mno-soft-float
                -mno-386 -m486 -mieee-fp -mfp-ret-in-387

  Utiliser un niveau d'optimisation superieur a celui que le compilateur
  supporte (par exemple -O6) aura le meme effet qu'utiliser le plus haut
  niveau  gere.  Distribuer  du code ou la compilation est configuree de
  cette maniere est une tres mauvaise idee -- si d'autres  optimisations
  sont   incorporees   dans  de  versions  futures,  vous  (ou  d'autres
  utilisateurs) pouvez vous apercevoir que cela ne compile plus, ou bien
  que le code genere ne fait pas les actions desirees.

  Les  utilisateurs  de  gcc  2.7.0 a 2.7.2 devraient noter qu'il y a un
  bogue dans l'option -O2. Plus precisement, la  _s_t_r_e_n_g_t_h  _r_e_d_u_c_t_i_o_n  ne
  fonctionne  pas.  Un patch a ete implemente pour resoudre ce probleme,
  mais vous devez alors recompiler  gcc.  Sinon,  vous  devrez  toujours
  compiler avec l'option -fno-strength-reduce.

  44..22..11..11..  SSppeecciiffiiccaattiioonn dduu pprroocceesssseeuurr

  Il  existe  d'autres  options  -m qui ne sont pas positionnees lors de
  l'utilisation de -O mais qui sont neanmoins utiles dans certains  cas.
  C'est  le  cas pour les options -m386 et -m486, qui indiquent a gcc de
  generer un code plus ou moins optimise pour l'un ou  l'autre  type  de
  processeur. Le code continuera a fonctionner sur les deux processeurs.
  Bien que le code pour 486 soit plus  important,  il  ne  ralentit  pas
  l'execution du programme sur 386.

  Il  n'existe  pas actuellement de -mpentium ou -m586.  Linus a suggere
  l'utilisation  des  options  -m486   -malign-loops=2   -malign-jumps=2
  -malign-functions=2,  pour  exploiter les optimisations du 486 tout en
  perdant de la place due aux problemes d'alignements (dont  le  Pentium
  n'a que faire).  Michael Meissner (de Cygnus) nous dit :

       "  Mon  avis  est que l'option  -mno-strength-reduce  permet
       d'obtenir un code plus rapide sur un x86 (nota : je ne parle
       pas du bogue _s_t_r_e_n_g_t_h _r_e_d_u_c_t_i_o_n, qui est un autre probleme).
       Cela s'explique en raison du peu de registres dont disposent
       ces processeurs (et la methode de GCC qui consiste a grouper
       les  registres  dans  l'ordre  inverse  au  lieu  d'utiliser
       d'autres  registres  n'arrange rien).  La _s_t_r_e_n_g_t_h _r_e_d_u_c_t_i_o_n
       consiste en fait a rajouter des registres pour remplacer les
       multiplications  par  des  additions.  Je suspecte egalement
       -fcaller-saves de ne pas arranger la situation. "

       Une autre idee est que -fomit-frame-pointer n'est pas  obli-
       gatoirement  une bonne idee.  D'un cote, cela peut signifier
       qu'un autre registre est  disponible  pour  une  allocation.
       D'un  autre  cote,  vue  la maniere dont les processeurs x86
       codent leur jeu d'instruction, cela peut  signifier  que  la
       pile  des  adresses  relatives  prend  plus de place que les
       adresses de fenetres relatives, ce qui signifie en clair que
       moins de cache est disponible pour l'execution du processus.
       Il faut preciser que l'option -fomit-frame-pointer, signifie
       que  le  compilateur doit constamment ajuster le pointeur de
       pile apres les appels, alors qu'avec une  fenetre,  il  peut
       laisser plusieurs appels dans la pile.

  Le mot final sur le sujet provient de Linus :

       Remarquez  que si vous voulez des performances maximales, ne
       me croyez pas : testez ! Il existe  tellement  d'options  de
       gcc,  et il est possible que cela ne soit une reelle optimi-
       sation que pour vous.

  44..22..22..

  IInntteerrnnaall ccoommppiilleerr eerrrroorr:: cccc11 ggoott ffaattaall ssiiggnnaall 1111

  Signal  11  correspond  au  signal  SIGSEGV,  ou   bien   _s_e_g_m_e_n_t_a_t_i_o_n
  _v_i_o_l_a_t_i_o_n.  Normalement,  cela signifie que le programme s'est melange
  les pointeurs et a essaye d'ecrire la ou il n'en a pas le droit. Donc,
  cela pourrait etre un bug de gcc.

  Toutefois,  gcc est un logiciel assez teste et assez remarquable de ce
  cote.  Il utilise un grand nombre de structures de donnees  complexes,
  et  un  nombre  impressionnant  de pointeurs. En resume, c'est le plus
  pointilleux des testeurs de memoire existants. Si vous _n_'_a_r_r_i_v_e_z _p_a_s _a
  _r_e_p_r_o_d_u_i_r_e  _l_e  _b_o_g_u_e  ---  si  cela  ne  s'arrete pas au meme endroit
  lorsque vous retentez la compilation --- c'est plutot un probleme avec
  votre  machine  (processeur,  memoire,  carte  mere  ou  bien  cache).
  NN''aannnnoonncceezz ppaass la decouverte d'un nouveau bogue  si  votre  ordinateur
  traverse  tous les tests du BIOS, ou s'il fonctionne correctement sous
  Windows ou autre : ces tests ne valent rien. Il en va de  meme  si  le
  noyau  s'arrete  lors  du `make zImage' !  `make zImage' doit compiler
  plus de 200 fichiers, et il en faut bien moins pour  arriver  a  faire
  echouer une compilation.

  Si  vous  arrivez  a reproduire le bogue et (mieux encore) a ecrire un
  petit programme qui permet de mettre en evidence cette  erreur,  alors
  vous  pouvez  envoyer le code soit a la FSF, soit dans la liste linux-
  gcc.   Consultez  la  documentation  de  gcc  pour  plus  de   details
  concernant les informations necessaires.

  44..33..  PPoorrttaabbiilliittee

  Cette  phrase  a ete dite un jour : si quelque chose n'a pas ete porte
  vers Linux alors ce n'est pas important de l'avoir :-).

  Plus serieusement, en general seules quelques  modifications  mineures
  sont necessaires car Linux repond a 100% aux specifications POSIX.  Il
  est generalement sympathique d'envoyer a  l'auteur  du  programme  les
  modifications  effectuees  pour que le programme fonctionne sur Linux,
  pour que lors d'une future version, un  `make'  suffise  pour  generer
  l'executable.

  44..33..11..  <<ssggttttyy..hh>>) Specificites BSD (notamment bsd_ioctl, daemon et

  Vous  pouvez compiler votre programme avec l'option -I/usr/include/bsd
  et faire l'edition de liens avec -lbsd (en ajoutant -I/usr/include/bsd
  a  la  ligne  CFLAGS  et  -lbsd  a la ligne LDFLAGS dans votre fichier
  Makefile).  Il  est   egalement   necessaire   de   ne   ppaass   ajouter
  -D__USE_BSD_SIGNAL si vous voulez que les signaux BSD fonctionnent car
  vous les avez inclus automatiquement avec la ligne  -I/usr/include/bsd
  et en incluant le fichier d'en-tete <signal.h>.

  44..33..22..

  SSiiggnnaauuxx _m_a_n_q_u_a_n_t_s ((SSIIGGBBUUSS, SIGEMT, SIGIOT, SIGTRAP, SIGSYS, etc.)

  Linux respecte les specifications POSIX. Ces  signaux  n'en  font  pas
  partie  (cf.  ISO/IEC  9945-1:1990  - IEEE Std 1003.1-1990, paragraphe
  B.3.3.1.1) :

       " Les signaux SIGBUS, SIGEMT, SIGIOT, SIGTRAP, et SIGSYS ont
       ete  omis  de  la  norme  POSIX.1  car leur comportement est
       dependant de l'implementation et donc ne peut etre  reperto-
       rie  d'une maniere satisfaisante.  Certaines implementations
  peuvent fournir ces signaux  mais  doivent  documenter  leur
  effet "

  La maniere la plus elegante de regler ce probleme est de redefinir ces
  signaux a SIGUNUSED.  La maniere _n_o_r_m_a_l_e de proceder est d'entourer le
  code avec les #ifdef appropries :

       #ifdef SIGSYS
       /* ... code utilisant les signaux non posix  .... */
       #endif

  44..33..33..

  CCooddee KK && RR

  GCC est un compilateur ANSI, or il existe beaucoup de code qui ne soit
  pas ANSI.

  Il n'y a pas grand chose a faire, sauf rajouter l'option  -traditional
  lors   de   la   compilation.   Il  effectue  certaines  verifications
  supplementaires. Consultez les pages info gcc.

  Notez que l'option -traditional a pour  unique  effet  de  changer  la
  forme  du  langage  accepte par gcc. Par exemple, elle active l'option
  -fwritable-strings, qui deplace toutes les chaines de caracteres  vers
  l'espace  de donnees (depuis l'espace de texte, ou elle ne peuvent pas
  etre modifiees). Ceci augmente la taille de la memoire occupee par  le
  programme.

  44..33..44..  lleess pprroottoottyyppeess dduu ccooddee

  LLeess ssyymmbboolleess dduu pprreepprroocceesssseeuurr pprroodduuiisseenntt uunn ccoonnfflliitt aavveecc

  Un des problemes frequents  se  produit  lorsque  certaines  fonctions
  standards  sont  definies  comme macros dans les fichiers d'en-tete de
  Linux  et  le  preprocesseur  refusera  de  traiter   des   prototypes
  identiques. Par exemple, cela peut arriver avec atoi() et atol().

  44..33..55..

  sspprriinnttff(())

  Parfois,  soyez prudent lorsque vous effectuez un portage a partir des
  sources  de  programmes  fonctionnant  sous  SunOs,  surtout  avec  la
  fonction sprintf(string, fmt, ...) car elle renvoie un pointeur sur la
  chaine de caracteres alors que Linux (suivant la norme ANSI)  retourne
  le nombre de caracteres recopies dans la chaine de caracteres.

  44..33..66..

  ffccnnttll et ses copains.  Ou se trouve la definition de FD_* et compagnie
  ?

  Dans  <sys/time.h>.   Si vous utilisez fcntl vous voudrez probablement
  inclure <unistd.h> egalement, pour avoir le prototype de la  fonction.

  D'une  maniere  generale, la page de manuel pour une fonction donne la
  liste des fichiers d'en-tete a inclure.

  44..33..77..  ccoommmmeenncceenntt ddaannss uunn eettaatt dd''aatttteennttee aaccttiivvee

  LLee ttiimmeeoouutt ddee sseelleecctt(()). Les programmes

  A une certaine epoque, le parametre timeout de  la  fonction  select()
  etait  utilise  en  lecture  seule.   C'est pourquoi la page de manuel
  comporte une mise en garde :

       select()  devrait  retourner  normalement  le  temps  ecoule
       depuis  le timeout initial, s'il s'est declenche, en modifi-
       ant la valeur pointee par le parametre time. Cela sera peut-
       etre  implemente  dans  les versions ulterieures du systeme.
       Donc, il n'est pas vraiment prudent de supposer que les don-
       nees  pointees  ne  seront  pas  modifiees lors de l'appel a
       select().

  Mais tout arrive avec  le  temps  !  Lors  d'un  retour  de  select(),
  l'argument   timeout  recevra  le  temps  ecoule  depuis  la  derniere
  reception de donnees. Si aucune donnee n'est arrivee, la  valeur  sera
  nulle, et les futurs appels a cette fonction utilisant le meme timeout
  auront pour resultat un retour immediat.

  Pour resoudre le probleme, il suffit de mettre la valeur timeout  dans
  la structure a chaque appel de select().  Le code initial etait

             struct timeval timeout;
             timeout.tv_sec = 1;
             timeout.tv_usec = 0;
             while (some_condition)
                   select(n,readfds,writefds,exceptfds,&timeout);

  et doit devenir :

             struct timeval timeout;
             while (some_condition)
             {
                   timeout.tv_sec = 1;
                   timeout.tv_usec = 0;
                   select(n,readfds,writefds,exceptfds,&timeout);
             }

  Certaines  versions  de  Mosaic  etaient connues a une certaine epoque
  pour avoir ce probleme.

  La  vitesse  de  rotation  du  globe   terrestre   etait   inversement
  proportionnelle a la vitesse de transfert des donnees !
  44..33..88..

  AAppppeellss ssyysstteemmeess iinntteerrrroommppuuss

  44..33..88..11..  SSyymmppttoommeess ::

  Lorsqu'un  processus  est  arrete  avec un Ctrl-Z et relance - ou bien
  lorsqu'un autre signal est declenche dans une situation  differente  :
  par exemple avec un Ctrl-C, la terminaison d'un processus, etc, on dit
  qu'il y a " interruption d'un appel systeme " ,  ou  bien  "  write  :
  erreur inconnue " ou des trucs de ce genre.

  44..33..88..22..  PPrroobblleemmeess ::

  Les  systemes  POSIX  verifient  les signaux plus souvent que d'autres
  Unix plus anciens. Linux peux lancer les gestionnaires de signaux :

  +o  d'une maniere asynchrone (sur un top d'horloge)

  +o  lors d'un retour de n'importe quel appel systeme

  +o  pendant  l'execution  des  appels  systemes  suivants  :  select(),
     pause(),   connect(),  accept(),  read()  sur  des  terminaux,  des
     sockets, des pipes ou des fichiers situes dans /proc,  write()  sur
     des  terminaux,  des  sockets, des pipes ou des imprimantes, open()
     sur  des  FIFOs,  des  lignes  PTYs  ou  series,  ioctl()  sur  des
     terminaux, fcntl() avec la commande F_SETLKW, wait4(), syslog(), et
     toute operation d'ordre TCP ou NFS.

  Sur d'autres systemes d'exploitation, il est possible que vous ayez  a
  inclure  dans  cette categorie les appels systemes suivants : creat(),
  close(),  getmsg(),  putmsg(),  msgrcv(),  msgsnd(),  recv(),  send(),
  wait(), waitpid(), wait3(), tcdrain(), sigpause(), semop().

  Si  un  signal  (que  le  programme  desire traiter) est lance pendant
  l'execution d'un appel systeme, le gestionnaire est lance. Lorsque  le
  gestionnaire du signal se termine, l'appel systeme detecte qu'il a ete
  interrompu et se termine avec la valeur  -1  et  errno  =  EINTR.   Le
  programme n'est pas forcement au courant de ce qui s'est passe et donc
  s'arrete.

  Vous pouvez choisir deux solutions pour resoudre ce probleme.

  (1)Dans tout gestionnaire de signaux que vous mettez en place, ajoutez
  l'option SA_RESTART au niveau de _s_i_g_a_c_t_i_o_n. Par exemple, modifiez

         signal (signal_id, mon_gestionnaire_de_signaux);

  en

    signal (signal_id, mon_gestionnaire_de_signaux);
    {
          struct sigaction sa;
          sigaction (signal_id, (struct sigaction *)0, &sa);
  #ifdef SA_RESTART
          sa.sa_flags |= SA_RESTART;
  #endif
  #ifdef SA_INTERRUPT
          sa.sa_flags &= ~ SA_INTERRUPT;
  #endif
          sigaction (signal_id, &sa, (struct sigaction *)0);
    }

  Notez  que  lors  de  certains  appels  systemes  vous  devrez souvent
  regarder si errno n'a pas ete positionnee a EINTR par vous meme  comme
  avec read(), write(), ioctl(), select(), pause() et connect().

  (2) A la recherche de EINTR :

  Voici deux exemples avec read() et ioctl(),

  Voici le code original utilisant read()

       int result;
       while (len > 0)
       {
         result = read(fd,buffer,len);
         if (result < 0)
               break;
         buffer += result;
         len -= result;
       }

  et le nouveau code

       int result;
       while (len > 0)
       {
         result = read(fd,buffer,len);
         if (result < 0)
         {
               if (errno != EINTR)
                       break;
         }
         else
         {
               buffer += result;
               len -= result;
         }
       }

  Voici un code utilisant  ioctl()

       int result;
       result = ioctl(fd,cmd,addr);

  et cela devient

       int result;
       do
       {
          result = ioctl(fd,cmd,addr);
       }
       while ((result == -1) && (errno == EINTR));

  Il  faut remarquer que dans certaines versions d'Unix de type BSD on a
  l'habitude  de  relancer   l'appel   systeme.   Pour   recuperer   les
  interruptions  d'appels  systemes,  vous  devez  utiliser  les options
  SV_INTERRUPT ou SA_INTERRUPT.

  44..33..99..  "" sseeggmmeennttaattiioonn ffaauulltt "" dd''uunnee mmaanniieerree aalleeaattooiirree))

  LLeess cchhaaiinneess eett lleeuurrss aacccceess eenn eeccrriittuurreess ((oouu lleess pprrooggrraammmmeess qquuii  pprroovvoo--
  qquueenntt ddeess

  GCC a une vue optimiste  en  ce  qui  concerne  ses  utilisateurs,  en
  croyant  qu'ils  respectent le fait qu'une chaine dite constante l'est
  reellement. Donc, il les range  dans la zone _t_e_x_t_e_(_c_o_d_e_) du programme,
  ou  elles  peuvent  etre  chargees puis dechargees a partir de l'image
  binaire de l'executable situee sur disque (ce qui evite  d'occuper  de
  l'espace  disque).  Donc, toute tentative d'ecriture dans cette chaine
  provoque un " segmentation fault ".

  Cela peut poser certains problemes avec d'anciens codes,  par  exemple
  ceux  qui  utilisent  la  fonction  mktemp() avec une chaine constante
  comme argument.  mktemp() essaye d'ecrire dans  la  chaine  passee  en
  argument.

  Pour resoudre ce probleme,

  1. compilez  avec  l'option  -fwritable-strings pour indiquer a gcc de
     mettre les chaines constantes dans l'espace de donnees

  2. reecrire les differentes parties du code pour  allouer  une  chaine
     non  constante  puis  effectuer  un strcpy des donnees dedans avant
     d'effectuer l'appel.

  44..33..1100..

  PPoouurrqquuooii ll''aappppeell aa eexxeeccll(()) echoue ?

  Tout simplement parce que vous l'utilisez  mal.  Le  premier  argument
  d'execl est le programme que vous desirez executer. Le second et ainsi
  de suite sont en fait le elements du tableau argv  que  vous  appelez.
  Souvenez-vous  que  argv[0]  est  traditionnellement  fixe  meme si un
  programme est lance sans argument. Vous devriez donc ecrire :

  execl("/bin/ls","ls",NULL);

  et pas

       execl("/bin/ls", NULL);

  Lancer le programme  sans  argument  est  considere  comme  etant  une
  demande   d'affichage   des   bibliotheques  dynamiques  associees  au
  programme, si vous utilisez le  format  a.out.  ELF  fonctionne  d'une
  maniere differente.

  (Si  vous desirez ces informations, il existe des outils plus simples;
  consultez la section sur le chargement dynamique, ou la page de manuel
  de ldd).

  55..  DDeebboogguueerr eett ooppttiimmiisseerr

  55..11..

  EEttuuddee pprreevveennttiivvee dduu ccooddee ((lliinntt))

  Il   n'existe  pas  de  lint  qui  soit  reellement  utilisable,  tout
  simplement  parce  que  la  grande  majorite  des  developpeurs   sont
  satisfaits  des  messages  d'avertissement de gcc. Il est probable que
  l'option la plus utile  est  l'option  -Wall  ---  qui  a  pour  effet
  d'afficher tous les avertissements possibles.

  Il  existe  une  version  du domaine public du programme lint que vous
  pouvez       trouver       a        l'adresse        suivante        :
  <ftp://larch.lcs.mit.edu/pub/Larch/lclint>.  Je ne sais pas ce qu'elle
  vaut.

  55..22..

  DDeebboogguueerr

  55..22..11..

  CCoommmmeenntt rreennddrree ddeebbooggaabbllee uunn pprrooggrraammmmee ??

  Vous devez compiler et effectuer l'edition de liens avec l'option  -g,
  et  sans  l'option  -fomit-frame-pointer.   En  fait,  vous  ne  devez
  compiler que les modules que vous avez besoin de deboguer.

  Si vous possedez un systeme a.out, les bibliotheques  dynamiques  sont
  compilees  avec  l'option  -fomit-frame-pointer,  que  gcc ne peut pas
  gerer. Lorsque vous compilez avec l'option -g, alors par  defaut  vous
  effectuez  une edition de liens statique, ce qui permet de resoudre le
  probleme.

  Si l'editeur de liens echoue avec un message disant qu'il n'arrive pas
  a  trouver  la  bibliotheque libg.a, c'est que vous ne possedez pas la
  bibliotheque /usr/lib/libg.a,  qui  est  la  bibliotheque  C  standard
  permettant  le  debogage.  Cette  bibliotheque  est  fournie  dans  le
  paquetage des binaires de la libc., ou (dans les  nouvelles  versions)
  vous  aurez besoin de recuperer le source et de le compiler vous-meme.
  Vous n'avez pas reellement besoin de cela en fait, vous  pouvez  faire
  un lien logique vers /usr/lib/libc.a

  55..22..11..11..

  CCoommmmeenntt rreedduuiirree llaa ttaaiillllee ddeess eexxeeccuuttaabblleess ??

  Bon  nombre  de  produits GNU sont fournis pour compiler avec l'option
  -g, ce qui genere des executables d'une  taille  tres  importante  (et
  souvent  l'edition  de  liens  s'effectue d'une maniere statique).  Ce
  n'est pas une idee lumineuse...

  Si le programme possede le script configure genere par autoconf,  vous
  pouvez  modifier  les options de debogage en effectuant un vous pouvez
  aller modifier le Makefile. Bien sur, si vous utilisez le format  ELF,
  l'edition  de  liens  sera  effectuee  de  maniere dynamique meme avec
  l'option  -g.  Dans  ce  cas,  vous  pouvez  effectuer  un  strip  sur
  l'executable.

  55..22..22..

  PPrrooggrraammmmeess ddiissppoonniibblleess

  Beaucoup  de gens utilisent ggddbb, que vous pouvez recuperer sur le site
  prep.ai.mit.edu  <ftp://prep.ai.mit.edu/pub/gnu>,   sous   une   forme
  binaire  sur  tsx-11  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC> ou
  sur sunsite.  xxxxggddbb est une surcouche X de gdb (c.a.d. que  vous  avez
  besoin de gdb pour utiliser xxgdb). Les sources peuvent etre recuperes
  sur  <ftp://ftp.x.org/contrib/xxgdb-1.08.tar.gz>

  Il existe egalement le debogueur UUPPSS qui a ete porte par Rick Sladkey.
  Il fonctionne sous X egalement, mais a la difference d'xxgdb, ce n'est
  qu'une surcouche X pour un debogueur en  mode  en  texte.  Il  possede
  certaines  caracteristiques  tres  interessantes  et  si vous utilisez
  beaucoup ce genre d'outils, vous  l'essayerez  surement.  Les  patches
  ainsi  que  des versions precompilees pour Linux peuvent etre trouvees
  sur <ftp://sunsite.unc.edu/pub/Linux/devel/debuggers/>, et les sources
  peuvent                etre                recuperes               sur
  <ftp://ftp.x.org/contrib/ups-2.45.2.tar.Z>.

  Un autre outil que vous pouvez  trouver  utile  pour  deboguer  est  "
  ssttrraaccee  " , qui affiche les appels systemes que le processus lance. Il
  possede  d'autres  caracteristiques  telles  que  donner  les  chemins
  d'acces ou ont ete compiles les binaires, donner les temps passes dans
  chacun des appels systemes, et il vous permet egalement  de  connaitre
  les  resultats des appels. La derniere version de strace (actuellement
  la version 3.0.8) peut etre trouvee sur  <ftp://ftp.std.com/pub/jrs/>.

  55..22..33..  PPrrooggrraammmmeess eenn ttaacchhee ddee ffoonndd ((ddeemmoonn))

  Les  demons  lancent  typiquement  un  fork()  des  leur  lancement et
  terminent donc le pere.  Cela  fait  une  session  de  deboguage  tres
  courte.

  La  maniere  la  plus  simple  de resoudre ce probleme est de poser un
  point d'arret sur fork, et lorsque le programme  s'arrete,  forcer  le
  retour a 0.

       (gdb) list
       1       #include <stdio.h>
       2
       3       main()
       4       {
       5         if(fork()==0) printf("child\n");
       6         else printf("parent\n");
       7       }
       (gdb) break fork
       Breakpoint 1 at 0x80003b8
       (gdb) run
       Starting program: /home/dan/src/hello/./fork
       Breakpoint 1 at 0x400177c4

       Breakpoint 1, 0x400177c4 in fork ()
       (gdb) return 0
       Make selected stack frame return now? (y or n) y
       #0  0x80004a8 in main ()
           at fork.c:5
       5         if(fork()==0) printf("child\n");
       (gdb) next
       Single stepping until exit from function fork,
       which has no line number information.
       child
       7       }

  55..22..44..  FFiicchhiieerrss ccoorree

  Lorsque  Linux  se  lance,  il  n'est  generalement pas configure pour
  produire des fichiers core. Si vous les  voulez  vous  devez  utiliser
  votre shell pour ca en faisant sous csh (ou tcsh) :

       % limit core unlimited

  avec sh, bash, zsh, pdksh, utilisez

       $ ulimit -c unlimited

  Si  vous  voulez  pousser  le  vice  a  nommer votre fichier core (par
  exemple si vous utilisez un debogueur bogue... ce qui est  un  comble)
  vous   pouvez  simplement  modifier  le  noyau.  Editez  les  fichiers
  fs/binfmt_aout.c et fs/binfmt_elf.c (dans les  nouveaux  noyaux,  vous
  devrez chercher ailleurs) :

          memcpy(corefile,"core.",5);
  #if 0
          memcpy(corefile+5,current->comm,sizeof(current->comm));
  #else
          corefile[4] = '\0';
  #endif

  et changez les 0 par des 1.

  55..33..  CCaarraacctteerriissttiiqquueess dduu pprrooggrraammmmee

  Il  est possible d'examiner un peu le programme pour savoir quels sont
  les appels de fonctions qui sont effectues le plus souvent ou bien qui
  prennent  du  temps.  C'est  une  bonne maniere d'optimiser le code en
  determinant la ou l'on passe le plus de temps.   Vous  devez  compiler
  tous  les  objets  avec l'option -p, et pour mettre en forme la sortie
  ecran, vous aurez besoin du programme gprof (situe dans les binutils).
  Consultez les pages de manuel gprof pour plus de details.

  66..  EEddiittiioonn ddee lliieennss

  Entre  les  deux  formats  de  binaires  incompatibles,  bibliotheques
  statiques et dynamiques, on peut  comparer  l'operation  d'edition  de
  lien  en  fait  a 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...

  Pour  dissiper  la  confusion qui regne, nous allons nous baser sur ce
  qui se passe lors  d'execution  d'un  programme,  avec  le  chargement
  dynamique.  Vous verrez egalement la description de l'edition de liens
  dynamiques, mais plus tard. Cette section est dediee  a  l'edition  de
  liens qui intervient a la fin de la compilation.

  66..11..  BBiibblliiootthheeqquueess ppaarrttaaggeeeess ccoonnttrree bbiibblliiootthheeqquueess ssttaattiiqquueess

  La derniere phase de  construction  d'un  programme  est  de  realiser
  l'edition  de  liens, ce qui consiste a assembler tous les morceaux du
  programme et de chercher ceux  qui  sont  manquants.  Bien  evidement,
  beaucoup de programmes realisent les memes operations comme ouvrir des
  fichiers  par  exemple,  et  ces  pieces  qui   realisent   ce   genre
  d'operations sont fournies sous la forme de bibliotheques. Sous Linux,
  ces bibliotheques peuvent etre  trouvees  dans  les  repertoires  /lib
  et/usr/lib/ entre autres.

  Lorsque  vous  utilisez  une bibliotheque statique, l'editeur de liens
  cherche le code dont votre programme a besoin et en effectue une copie
  dans  le  programme physique genere. Pour les bibliotheques partagees,
  c'est le contraire : l'editeur de liens laisse du  code  qui  lors  du
  lancement  du  programme  chargera automatiquement la bibliotheque. Il
  est evident que ces bibliotheques permettent d'obtenir  un  executable
  plus  petit; elles permettent egalement d'utiliser moins de memoire et
  moins de place disque. Linux effectue par defaut une edition de  liens
  dynamique  s'il  peut  trouver  les bibliotheques de ce type sinon, il
  effectue une edition de liens statique. Si vous obtenez  des  binaires
  statiques  alors  que  vous  les  voulez  dynamiques  verifiez que les
  bibliotheques existent (*.sa pour le format a.out,  et  *.so  pour  le
  format  ELF) et que vous possedez les droits suffisants pour y acceder
  (lecture).

  Sous Linux, les bibliotheques statiques ont pour nom  libnom.a,  alors
  que  les  bibliotheques  dynamiques  sont appelees libnnom.so.x.y.z ou
  x.y.z represente le numero de version.  Les  bibliotheques  dynamiques
  ont  souvent  des liens logiques qui pointent dessus, et qui sont tres
  importants. Normalement, les bibliotheques standards sont livrees sous
  la double forme dynamique et statique.

  Vous  pouvez savoir de quelles bibliotheques dynamiques un programme a
  besoin en utilisant la commande ldd (_L_i_s_t _D_y_n_a_m_i_c _D_e_p_e_n_d_e_n_c_i_e_s)

       $ ldd /usr/bin/lynx
               libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
               libc.so.5 => /lib/libc.so.5.2.18

  Cela indique sur mon systeme que l'outil lynx (outil WWW) a besoin des
  bibliotheques   dynamiques   libc.so.5   (la  bibliotheque  C)  et  de
  libncurses.so.1 (necessaire pour le  controle  du  terminal).   Si  un
  programme  ne  possede  pas  de dependances, ldd indiquera `_s_t_a_t_i_c_a_l_l_y
  _l_i_n_k_e_d' (edition de liens statique).

  66..22..

  AA llaa rreecchheerrcchhee ddeess ffoonnccttiioonnss...... oouu ddaannss qquueellllee bbiibblliiootthheeqquuee ssee  ttrroouuvvee
  llaa ffoonnccttiioonn ssiinn(()) ?')

  nm _n_o_m_d_e_b_i_b_l_i_o_t_h_e_q_u_e vous donne tous les symboles references  dans  la
  bibliotheque.  Cela  fonctionne  que  cela  soit  du  code statique ou
  dynamique.  Supposez que vous vouliez savoir ou se trouve  definie  la
  fonction tcgetattr() :

       $ nm libncurses.so.1 |grep tcget
                U tcgetattr

  La  lettre  U  vous  indique  que  c'est indefini (_U_n_d_e_f_i_n_e_d) --- cela
  indique que la bibliotheque ncurses l'utilise mais ne la definit  pas.
  Vous pouvez egalement faire :

       $ nm libc.so.5 | grep tcget
       00010fe8 T __tcgetattr
       00010fe8 W tcgetattr
       00068718 T tcgetpgrp

  La  lettre `W' indique que le symbole est defini mais de telle maniere
  qu'il peut etre surcharge par une autre definition de la fonction dans
  une autre bibliotheque (W pour _w_e_a_k : faible).  Une definition normale
  est marquee par la lettre `T' (comme pour tcgetpgrp).

  La reponse a la question situee dans le titre est libm.(so|a).  Toutes
  les  fonctions  definies  dans  le  fichier  d'en-tete  <math.h>  sont
  implementees  dans  la  bibliotheque  mathematique  donc  vous  devrez
  effectuer l'edition de liens grace a -lm.

  66..33..  TTrroouuvveerr lleess ffiicchhiieerrss

  Supposons  que  vous  ayez  le  message d'erreur suivant de la part de
  l'editeur de liens :

  ld: Output file requires shared library `libfoo.so.1`

  La strategie de recherche de fichiers de ld ou de ses copains  differe
  de  la  version  utilisee,  mais vous pouvez etre sur que les fichiers
  situes dans le repertoire /usr/lib seront trouves. Si vous desirez que
  des  fichiers  situes  a  un  endroit different soient trouves, il est
  preferable d'ajouter l'option -L a gcc ou ld.

  Si cela ne vous aide pas clairement, verifiez que  vous  avez  le  bon
  fichier  a  l'endroit  specifie.  Pour  un  systeme  a.out,  effectuer
  l'edition  de  liens  avec  -ltruc  implique  que  ld  recherche   les
  bibliotheques    libtruc.sa  (bibliotheques  partagees),  et  si  elle
  n'existe pas, il recherche libtruc.a (statique).  Pour le format  ELF,
  il  cherche libtruc.so puis libtruc.a.  libtruc.so est generalement un
  lien symbolique vers libtruc.so.x.

  66..44..  CCoommppiilleerr vvoottrree pprroopprree bbiibblliiootthheeqquuee

  66..44..11..  NNuummeerroo ddee llaa vveerrssiioonn

  Comme tout programme, les bibliotheques ont tendance a avoir  quelques
  bogues   qui   sont   corriges  au  fur  et  a  mesure.  De  nouvelles
  fonctionnalites sont ajoutees et qui peuvent changer l'effet de celles
  qui  existent  ou  bien  certaines anciennes peuvent etres supprimees.
  Cela peut etre un probleme pour les programmes qui les utilisent.

  Donc,  nous  introduisons  la  notion  de  numero  de  version.   Nous
  repertorions  les modifications effectuees dans la bibliotheques comme
  etant soit mineures soit majeures. Cela signifie  qu'une  modification
  mineure  ne  peut  pas  modifier  le fonctionnement d'un programme (en
  bref, il continue a fonctionner comme avant). Vous  pouvez  identifier
  le  numero  de  la version de la bibliotheque en regardant son nom (en
  fait c'est un mensonge pour les bibliotheques ELF... mais continuez  a
  faire comme si !) : libtruc.so.1.2 a pour version majeure 1 et mineure
  2.  Le numero de version mineur peut etre plus ou moins eleve  ---  la
  bibliotheque  C  met un numero de patch, ce qui produit un nom tel que
  libc.so.5.2.18, et c'est egalement courant d'y trouver des lettres  ou
  des blancs soulignes ou tout autre caractere ASCII affichable.

  Une  des  principales  differences  entre  les formats ELF et a.out se
  trouve dans la maniere de construire la bibliotheque  partagee.   Nous
  traiterons  les  bibliotheques  partagees  en  premier  car c'est plus
  simple.

  66..44..22..

  EELLFF,, qquu''eesstt--ccee qquuee cc''eesstt ??

  ELF (_E_x_e_c_u_t_a_b_l_e _a_n_d _L_i_n_k_i_n_g _F_o_r_m_a_t) est format de binaire initialement
  concu  et developpe par USL (_U_N_I_X _S_y_s_t_e_m _L_a_b_o_r_a_t_o_r_i_e_s) et utilise dans
  les  systemes  Solaris  et  System  R4.  En  raison  de  sa   facilite
  d'utilisation  par  rapport  a  l'ancien format dit a.out qu'utilisait
  Linux, les developpeurs de GCC et de  la  bibliotheque  C  ont  decide
  l'annee  derniere  de basculer tout le systeme sous le format ELF. ELF
  est desormais le format binaire standard sous Linux.

  66..44..22..11..  EELLFF,, llee rreettoouurr !!

  Ce paragraphe provient du groupe '/news-archives/comp.sys.sun.misc'.

       ELF (_E_x_e_c_u_t_a_b_l_e _L_i_n_k_i_n_g _F_o_r_m_a_t) 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  ou  il  est  extensible. ELF voit un fichier objet
       comme une longue liste de sections (plutot qu'un tableau  de
       taille  fixe  d'elements).  Ces sections, a la difference de
       COFF ne se trouvent pas a un endroit constant et ne sont pas
       dans  un  ordre  particulier,  etc. Les utilisateurs peuvent
       ajouter une nouvelle section  a  ces  fichiers  objets  s'il
       desirent  y mettre de nouvelles donnees. ELS possede un for-
       mat de debogage plus puissant appele DWARF  (_D_e_b_u_g_g_i_n_g  _W_i_t_h
       _A_t_t_r_i_b_u_t_e  _R_e_c_o_r_d  _F_o_r_m_a_t) - par encore entierement gere par
       Linux (mais on y travaille !).  Une liste chainee de " DWARF
       DIEs " (ou _D_e_b_u_g_g_i_n_g _I_n_f_o_r_m_a_t_i_o_n _E_n_t_r_i_e_s - NdT... le lecteur
       aura surement note le jeu de mot assez noir : dwarf =  nain;
       dies  =  morts)  forment la section _._d_e_b_u_g 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  ecrits  sous  la
       forme  d'un arbre de donnees.  Les DIEs peuvent contenir une
       plus grande quantite d'information que la section _._d_e_b_u_g  du
       format  COFF  ne le pouvait (un peu comme les graphes d'her-
       itages du C++).

       Les fichiers ELF sont accessibles grace  a  la  bibliotheque
       d'acces  de  SVR4 (Solaris 2.0 peut-etre ?), qui fournit une
       interface simple et rapide aux parties  les  plus  complexes
       d'ELF.  Une  des aubaines que permet la bibliotheque d'acces
       ELF est que vous n'avez jamais besoin de connaitre les mean-
       dres  du  format  ELF.  Pour  acceder  a un fichier Unix, on
       utilise un Elf  *,  retourne  par  un  appel  a  elf_open().
       Ensuite,  vous  effectuez  des  appels  a  elf_foobar() pour
       obtenir les differents composants au lieu d'avoir a triturer
       le  fichier  physique  sur  le  disque  (chose  que beaucoup
       d'utilisateurs de COFF ont fait...).

  Les arguments pour ou contre ELF, et les problemes lies a  la  mise  a
  jour  d'un systeme a.out vers un systeme ELF sont decrits dans le ELF-
  HOWTO et je ne veux pas effectuer de copier coller ici (NdT: ce  HowTo
  est  egalement  traduit  en  francais).   Ce  HowTo  se trouve au meme
  endroit que les autres.

  66..44..22..22..  LLeess bbiibblliiootthheeqquuee ppaarrttaaggeeeess EELLFF

  Pour construire libtruc.so comme une bibliotheque dynamique, il suffit
  de suivre les etapes suivantes :

       $ 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

  Cela  va generer une bibliotheque partagee appelee libtruc.so.1.0, les
  liens  appropries  pour  ld  (libtruc.so)  et  le  chargeur  dynamique
  (libtruc.so.1)  pour  le  trouver.   Pour  tester,  nous  ajoutons  le
  repertoire actuel a la variable d'environnement LD_LIBRARY_PATH.

  Lorsque vous etes satisfait et que la  bibliotheque  fonctionne,  vous
  n'avez   plus  qu'a  la  deplacer  dans  le  repertoire  par  exemple,
  /usr/local/lib, et  de  recreer  les  liens  appropries.  Le  lien  de
  libtruc.so.1  sur  libtruc.so.1.0 est enregistre par ldconfig, qui sur
  bon nombre de systemes est lance lors du processus d'amorcage. Le lien
  libfoo.so  doit  etre  mis  a jour a la main. Si vous faites attention
  lors de la mise a jour de la bibliotheque la chose la  plus  simple  a
  realiser  est  de  creer  le  lien  libfoo.so -> libfoo.so.1, pour que
  ldconfig conserve les liens actuels. Si vous ne faites pas cela,  vous
  aurez  des problemes plus tard. Ne me dites pas que l'on ne vous a pas
  prevenu !

       $ /bin/su
       # cp libtruc.so.1.0 /usr/local/lib
       # /sbin/ldconfig
       # ( cd /usr/local/lib ; ln -s libtruc.so.1 libtruc.so )

  66..44..22..33..

  LLeess nnuummeerrooss ddee vveerrssiioonn,, lleess nnoommss eett lleess lliieennss

  Chaque bibliotheque possede un nom propre (_s_o_n_a_m_e).  Lorsque l'editeur
  de  liens  en trouve un qui correspond a un nom cherche, il enregistre
  le nom de la bibliotheque dans le code binaire au lieu d'y  mettre  le
  nom  du  fichier  de la bibliotheque. Lors de l'execution, le chargeur
  dynamique va alors chercher un fichier ayant pour nom le nom propre de
  la  bibliotheque,  et  pas  le  nom du fichier de la bibliotheque. Par
  exemple, une bibliotheque ayant pour nom libtruc.so peut  avoir  comme
  nom  propre  libbar.so,  et  tous  les programmes lies avec vont alors
  chercher libbar.so lors de leur execution.

  Cela semble etre une nuance un peu pointilleuse mais c'est la clef  de
  la  comprehension  de la coexistence de plusieurs versions differentes
  de la meme bibliotheque sur le meme systeme.  On a pour habitude  sous
  Linux d'appeler une bibliotheque libtruc.so.1.2 par exemple, et de lui
  donner comme nom  propre  libtruc.so.1.   Si  cette  bibliotheque  est
  rajoutee  dans  un repertoire standard (par exemple dans /usr/lib), le
  programme ldconfig va creer un lien symbolique entre  libtruc.so.1  ->
  libtruc.so.1.2  pour  que  l'image  appropriee  soit  trouvee  lors de
  l'execution.  Vous  aurez  egalement  besoin  d'un   lien   symbolique
  libtruc.so  ->  libtruc.so.1  pour que ld trouve le nom propre lors de
  l'edition de liens.
  Donc, lorsque vous corrigez des erreurs dans la bibliotheque  ou  bien
  lorsque  vous  ajoutez  de  nouvelles  fonctions  (en fait, pour toute
  modification  qui  n'affecte  pas  l'execution  des  programmes   deja
  existants),  vous  reconstruisez  la  bibliotheque,  conservez  le nom
  propre tel qu'il etait et changez le  nom  du  fichier.  Lorsque  vous
  effectuez  des  modifications  que peuvent modifier le deroulement des
  programmes existants,  vous  pouvez  tout  simplement  incrementer  le
  nombre  situe  dans le nom propre --- dans ce cas, appelez la nouvelle
  version de la bibliotheque libtruc.so.2.0,  et  donnez-lui  comme  nom
  propre  libtruc.so.2.  Maintenant, faites pointer le lien de libfoo.so
  vers la nouvelle version et tout est bien dans le meilleur des  mondes
  !

  Il  est  utile  de  remarquer que vous n'etes pas oblige de nommer les
  bibliotheques de cette maniere, mais c'est une bonne convention.   Elf
  vous  donne une certaine liberte pour nommer des bibliotheques tant et
  si bien que cela peut perturber certains utilisateurs,  mais  cela  ne
  veut pas dire que vous etes oblige de le faire.

  Resume : supposons que choisissiez d'adopter la methode traditionnelle
  avec les mises a jour majeures qui peuvent  ne  pas  etre  compatibles
  avec  les  versions  precedentes  et  les mises a jour mineures qui ne
  posent pas ce probleme. Il suffit de creer la  bibliotheque  de  cette
  maniere :

       gcc -shared -Wl,-soname,libtruc.so.majeur -o libtruc.so.majeur.mineur

  et tout devrait etre parfait !

  66..44..33..  aa..oouutt..  LLee bboonn vviieeuuxx ffoorrmmaatt

  La  facilite  de  construire  des bibliotheque partagees est la raison
  principale de passer a ELF. Ceci dit,  il  est  toujours  possible  de
  creer  des  bibliotheques  dynamiques  au  format  a.out. Recuperez le
  fichier                                                        archive
  <ftp://tsx-11.mit.edu/pub/linux/packages/GCC/src/tools-2.17.tar.gz> et
  lisez les 20 pages de documentation que vous  trouverez  dedans  apres
  l'avoir  desarchive.  Je n'aime pas avoir l'air d'etre aussi partisan,
  mais il est clair que je n'ai jamais aime ce format :-).

  66..44..33..11..

  ZZMMAAGGIICC ccoonnttrree QQMMAAGGIICC

  QMAGIC est le format des executables qui ressemble un  peu  aux  vieux
  binaires  a.out  (egalement  connu  comme  ZMAGIC), mais qui laisse la
  premiere page libre. Cela permet  plus  facilement  de  recuperer  les
  adresses  non  affectees  (comme NULL) dans l'intervalle 0-4096 (NdT :
  Linux utilise des pages de 4Ko).

  Les editeurs de liens desuets ne gerent que le format ZMAGIC, ceux  un
  peu moins rustiques gerent les deux, et les plus recents uniquement le
  QMAGIC. Cela importe peu car le noyau gere les deux types.

  La commande file est capable d'identifier si un programme est de  type
  QMAGIC.

  66..44..33..22..  GGeessttiioonn ddeess ffiicchhiieerrss

  Une  bibliotheque  dynamique a.out (DLL) est composee de deux fichiers
  et d'un lien symbolique. Supposons que l'on  utilise  la  bibliotheque
  _t_r_u_c,   les   fichiers   seraient   les   suivants   :  libtruc.sa  et
  libtruc.so.1.2; et le lien symbolique aurait pour nom libtruc.so.1  et
  pointerait sur le dernier des fichiers. Mais a quoi servent-ils ?

  Lors  de  la  compilation, ld cherche libtruc.sa.  C'est le fichier de
  description de la  bibliotheque  :  il  contient  toutes  les  donnees
  exportees  et  les  pointeurs  vers  les  fonctions  necessaires  pour
  l'edition de liens.

  Lors de  l'execution,  le  chargeur  dynamique  cherche  libtruc.so.1.
  C'est  un  lien  symbolique  plutot  qu'un  reel  fichier pour que les
  bibliotheques puissent etre mise  a  jour  sans  avoir  a  casser  les
  applications  qui  utilisent  la  bibliotheque.  Apres la mise a jour,
  disons que l'on est passe a la version libfoo.so.1.3, le lancement  de
  ldconfig  va  positionner le lien. Comme cette operation est atomique,
  aucune application fonctionnant n'aura de probleme.

  Les bibliotheques DLL (Je sais que c'est une tautologie... mais pardon
  !)   semblent  etre  tres souvent plus importantes que leur equivalent
  statique. En fait, c'est qu'elles  reservent  de  la  place  pour  les
  extensions  ulterieures sous la simple forme de trous qui sont fait de
  telle maniere qu'ils n'occupent pas de place  disque  (NdT  :  un  peu
  comme  les  fichiers  core).  Toutefois,  un  simple  appel  a cp ou a
  makehole les remplira...  Vous pouvez effectuer une operation de strip
  apres  la  construction  de la bibliotheque, comme les adresses sont a
  des endroits  fixes.   NNee  ffaaiitteess  ppaass  llaa  mmeemmee  ooppeerraattiioonn  aavveecc  lleess
  bbiibblliiootthheeqquueess EELLFF !!

  66..44..33..33..  "" lliibbcc--lliittee "" ??

  Une  "  libc-lite  "  (contraction  de _l_i_b_c et _l_i_t_t_l_e) est une version
  epuree et reduite de la bibliotheque libc construite de telle  maniere
  qu'elle  puisse tenir sur une disquette avec un certain nombre d'outil
  Unix.   Elle  n'inclut  pas  curses,  dbm,  termcap,  ...   Si   votre
  /lib/libc.so.4  est liee avec une bibliotheque de ce genre il est tres
  fortement conseille de la remplacer avec une version complete.

  66..44..44..  EEddiittiioonn ddee lliieennss :: pprroobblleemmee ccoouurraannttss

  Envoyez-les moi !

      DDeess pprrooggrraammmmeess ssttaattiiqquueess lloorrssqquuee vvoouuss lleess vvoouulleezz
        partages"

        Verifiez que vous avez les bons liens pour que ld puisse trouver
        les  bibliotheques  partagees.  Pour  ELF  cela  veut  dire  que
        libtruc.so est un lien symbolique sur son image, pour  a.out  un
        fichier  libtruc.sa.   Beaucoup  de personnes ont eu ce probleme
        apres etre passes des outils ELF 2.5 a  2.6  (binutils)  ---  la
        derniere  version  effectue une recherche plus intelligente pour
        les bibliotheques dynamiques et donc ils n'avaient pas cree tous
        les  liens symboliques necessaires.  Cette caracteristique avait
        ete supprimee pour des raisons de  compatibilite  avec  d'autres
        architectures  et  parce  qu'assez  souvent cela ne marchait pas
        bien. En bref, cela posait plus de problemes qu'autre chose.

      LLee pprrooggrraammmmee ``mmkkiimmaaggee'' nn''aarrrriivvee ppaass aa ttrroouuvveerr lliibbggcccc

        Comme  libc.so.4.5.x  et  suivantes,  libgcc   n'est   pas   une
        bibliotheque  partagee.  Vous devez remplacer les `-lgcc' sur la
        ligne  de  commande  par  `gcc  -print-libgcc-file-name`  (entre
        quotes)

        Egalement,    detruisez    tous   les   fichiers   situes   dans
        /usr/lib/libgcc*.  C'est important.

      LLee mmeessssaaggee ____NNEEEEDDSS__SSHHRRLLIIBB__lliibbcc__44 mmuullttiippllyy ddeeffiinneedd
        Sont une consequence du meme probleme.

      LLee mmeessssaaggee ````AAsssseerrttiioonn ffaaiilluurree'''' aappppaarraaiitt lloorrssqquuee vvoouuss
        rreeccoonnssttrruuiisseezz uunnee
        DLL"  Ce  message  enigmatique  signifie  qu'un element de votre
        table _j_u_m_p a depasse la  table  car  trop  peu  de  place  etait
        reservee  dans  le  fichier jump.vars file.  Vous pouvez trouver
        le(s) coupable(s) en lancant la commande getsize fournie dans le
        paquetage  tools-2.17.tar.gz.  La seule solution est de passer a
        une nouvelle version majeure, meme  si  elle  sera  incompatible
        avec les precedentes.

      lldd:: oouuttppuutt ffiillee nneeeeddss sshhaarreedd lliibbrraarryy lliibbcc..ssoo..44
        Cela  arrive  lorsque vous effectuez l'edition de liens avec des
        bibliotheques differentes de la libc (comme les bibliotheques X)
        et que vous utilisez l'option -g sans utiliser l'option -static.

        Les fichiers  .sa  pour  les  bibliotheques  dynamiques  ont  un
        symbole  non  resolu  _NEEDS_SHRLIB_libc_4  qui  est defini dans
        libc.sa.  Or, lorsque vous utilisez -g vous faites l'edition  de
        liens  avec  libg.a  ou  libc.a  et donc ce symbole n'est jamais
        defini.

        Donc,  pour  resoudre  le  probleme,  ajoutez  l'option  -static
        lorsque  vous  compilez  avec  l'option -g, ou n'utilisez pas -g
        lors de l'edition de liens !

  77..  CChhaarrggeemmeenntt ddyynnaammiiqquuee

  _C_e _p_a_r_a_g_r_a_p_h_e _e_s_t _e_n _f_a_i_t _u_n _p_e_u _c_o_u_r_t  _:  _i_l  _s_e_r_a  _e_t_e_n_d_u  _d_a_n_s  _u_n_e
  _v_e_r_s_i_o_n _u_l_t_e_r_i_e_u_r_e _d_e_s _q_u_e _j_'_a_u_r_a_i _r_e_c_u_p_e_r_e _l_e _H_o_w_T_o _E_L_F

  77..11..  CCoonncceeppttss

  Linux  possede  des  bibliotheques dynamiques, comme on vous le repete
  depuis le debut de ce  document  !  Or,  il  existe  un  systeme  pour
  reporter  le  travail  d'association  des noms des symboles et de leur
  adresse dans la bibliotheque, qui est  normalement  effectue  lors  de
  l'edition de liens en l'effectuant lors du chargement du programme.

  77..22..  MMeessssaaggeess dd''eerrrreeuurr

  Envoyez  moi  vos  erreurs  !   Je  n'en fait pas grand chose sauf les
  inserer dans ce paragraphe...

      ccaann''tt llooaadd lliibbrraarryy:: //lliibb//lliibbxxxxxx..ssoo,, IInnccoommppaattiibbllee vveerrssiioonn
        (seulement a.out) Cela signifie que vous n'avez pas  la  version
        correcte  de  la bibliotheque (numero dit majeur). Non, il n'est
        pas possible d'effectuer un lien symbolique sur la  bibliotheque
        que  vous  possedez : si vous avez de la chance, vous obtiendrez
        un _s_e_g_m_e_n_t_a_t_i_o_n  _f_a_u_l_t.   Recuperez  la  nouvelle  version.   Un
        message  un peu equivalent existe egalement sur les systemes ELF
        :

          ftp: can't load library 'libreadline.so.2'

     wwaarrnniinngg uussiinngg iinnccoommppaattiibbllee lliibbrraarryy vveerrssiioonn xxxxxx
        (seulement a.out) Vous avez un numero de version de bibliotheque
        (mineur)  inferieur  a la version avec laquelle a ete compile le
        programme.  Le programme fonctionnera surement. Une mise a  jour
        est toutefois conseillee.

  77..33..

  CCoonnttrroolleerr ll''ooppeerraattiioonn ddee cchhaarrggeemmeenntt ddyynnaammiiqquuee

  Il   existe  certaines  variables  d'environnements  que  le  chargeur
  dynamique utilise. Beaucoup  sont  exploitees  par  le  programme  ldd
  lorsqu'il    s'agit    de   particularites   de   l'environnement   de
  l'utilisateur, ce qui peuvent etre positionnees pour lancer  ldd  avec
  des  options  particulieres.  Voici  une  description  des differentes
  variables d'environnement que vous pouvez rencontrer :

  +o  LD_BIND_NOW --- normalement, les fonctions ne  sont  pas  cherchees
     dans  les  bibliotheques  avant  leur  appel. En positionnant cette
     option, vous verifiez que toutes les fonctions employees dans votre
     programmes  se  trouvent  bien  dans  la  bibliotheque  lors de son
     chargement, ce qui ralentit le lancement du programme. C'est  utile
     lorsque   vous   voulez   tester   que  l'edition  de  liens  s'est
     parfaitement deroulee et que tous les symboles sont bien  associes.

  +o  LD_PRELOAD peut etre defini avec un nom de fichier qui contient des
     fonctions surchargeant des fonctions deja existantes.  Par exemple,
     si  vous  testez  une  strategie  d'allocation memoire, et que vous
     voulez remplacer le malloc de la bibliotheque C par le votre  situe
     dans un module ayant pour nom malloc.o, il vous suffit de faire :

       $ export LD_PRELOAD=malloc.o
       $ test_mon_malloc

  LD_ELF_PRELOAD  et LD_AOUT_PRELOAD sont similaires, mais leur utilisa-
  tion  est  specifique  au  type  de  binaire  utilise.  Si  LD__T_y_p_e_B_i_-
  _n_a_i_r_e_PRELOAD  et  LD_PRELOAD sont positionnes, celui correspondant le
  mieux a la machine est utilise.

  +o  LD_LIBRARY_PATH contient une liste  de  repertoires  contenant  les
     bibliotheques  dynamiques.  Cela n'affecte pas l'edition de liens :
     cela n'a qu'un effet lors de l'execution. Il faut noter qu'elle est
     desactivee pour des programmes qui s'executent avec un setuid ou un
     setgid.  Enfin, LD_ELF_LIBRARY_PATH et LD_AOUT_LIBRARY_PATH peuvent
     etre  utilises  pour  orienter  le  mode de compilation du binaire.
     LD_LIBRARY_PATH ne  devrait  pas  etre  necessaire  en  principe  :
     ajoutez   les  repertoires  dans  le  fichier  /etc/ld.so.conf/  et
     relancez ldconfig.

  +o  LD_NOWARN s'applique au format a.out uniquement.   Lorsqu'elle  est
     positionnee  (c.a.d si elle existe par exemple avec LD_NOWARN=true;
     export LD_NOWARN) cela arrete le chargeur du programme meme sur des
     avertissements     insignifiants    (tels    que    des    messages
     d'incompatibilites de numeros mineurs de version).

  +o  LD_WARN s'applique a ELF uniquement.  Lorsqu'elle est  positionnee,
     on transforme le message habituellement fatal _C_a_n_'_t _f_i_n_d _l_i_b_r_a_r_y en
     un avertissement. Ce n'est pas positionne  par  defaut  mais  c'est
     important pour un programme comme ldd.

  +o  LD_TRACE_LOADED_OBJECTS  s'applique  a ELF uniquement, et permet de
     simuler l'execution des programmes comme s'ils l'etaient par ldd :

       $ LD_TRACE_LOADED_OBJECTS=true /usr/bin/lynx
               libncurses.so.1 => /usr/lib/libncurses.so.1.9.6
               libc.so.5 => /lib/libc.so.5.2.18

  77..44..

  EEccrriirree ddeess pprrooggrraammmmeess eenn uuttiilliissaanntt llee cchhaarrggeemmeenntt ddyynnaammiiqquuee

  Cela  ressemble  enormement au systeme de chargement dynamique utilise
  sous Solaris 2.x. Ce systeme est decrit d'une maniere precise dans  le
  document expliquant la programmation avec ELF ecrit par H J Lu et dans
  la page de manuel dlopen(3), qui se trouve dans  le  paquetage  ld.so.
  Voici un exemple simple : pensez a faire l'edition de liens avec -ldl

       #include <dlfcn.h>
       #include <stdio.h>

       main()
       {
         void *libc;
         void (*printf_call)();

         if(libc=dlopen("/lib/libc.so.5",RTLD_LAZY))
         {
           printf_call = dlsym(libc,"printf");
           (*printf_call)("Bonjour ! Ha ben ca marche pil poil sous Linux !\n");
         }

       }

  88..  CCoonnttaacctteerr lleess ddeevveellooppppeeuurrss

  88..11..

  AAnnnnoonncceerr ddeess bboogguueess

  Commencez  par  mettre en doute le probleme. Est-ce specifique a Linux
  ou bien cela arrive avec gcc mais sur d'autres plates-formes ?  Est-ce
  specifique a la version du noyau ? A la version de la bibliotheque C ?
  Est-ce que ce probleme disparait lorsque vous effectuez une edition de
  liens  statique  ?  Pouvez-vous produire un code tres court mettant en
  evidence le probleme ?

  Apres avoir repondu apres ces quelques  questions,  vous  saurez  quel
  programme  est  a  l'origine du probleme. Pour un probleme direct avec
  GCC, le mieux est de consulter le fichier d'information livre  avec  :
  la  procedure pour rapporter un bogue y est detaille. Pour un probleme
  avec ld.so, la bibliotheque C ou  mathematique,  envoyez  un  courrier
  electronique  a  linux-gcc@vger.rutgers.edu.   Si  possible, donnez un
  court exemple mettant en evidence  le  probleme  ainsi  qu'une  courte
  description indiquant ce que le programme aurait normalement du faire,
  et ce qu'il fait en realite.

  88..22..  PPaarrttiicciippeerr aauu ddeevveellooppppeemmeenntt

  Si  vous  desirez  participer  au  developpement  de  GCC  ou  de   la
  bibliotheque C, la premiere chose a faire est de rejoindre la liste de
  diffusion  linux-gcc@vger.rutgers.edu.   Si  vous  desirez  uniquement
  savoir   de  quoi  ca  parle,  il  existe  des  archives  a  l'adresse
  <http://homer.ncm.com/linux-gcc/>.  Tout depend de ce que vous desirez
  faire ou apporter a ce projet !

  99..  DDiivveerrss

  99..11..  CCee ddooccuummeenntt

  Ce  HowTo  est  base  sur  la  FAQ de Mitchum DSouza's. Bon nombre des
  informations en proviennent. D'une maniere generale, il  est  frequent
  de  dire  une  phrase  du genre " je n'ai pas tout teste et donc ne me
  blamez pas si vous cassez votre  disque,  votre  systeme  ou  si  vous
  rompez avec votre epouse ".

  Le  nom  des  contributeurs  a  ce  document  sont  donnes  par  ordre
  alphabetique : Andrew Tefft, Axel Boldt, Bill Metzenthen, Bruce Evans,
  Bruno  Haible,  Daniel  Barlow,  Daniel  Quinlan,  David  Engel,  Dirk
  Hohndel, Eric Youngdale, Fergus Henderson, H.J. Lu, Jens Schweikhardt,
  Kai  Petzke,  Michael  Meissner,  Mitchum  DSouza,  Olaf  Flebbe, Paul
  Gortmaker, Rik Faith, Steven S. Dick, Tuomas  J  Lukka,  et  bien  sur
  Linus  Torvalds,  sans  qui  ce genre d'exercice aurait ete difficile,
  voir impossible :-)

  Ne soyez pas offense si votre nom n'apparait pas dans la liste et  que
  vous  ayez  contribue a ce document (sous la forme d'un HowTo ou d'une
  FAQ).   Envoyez-moi  un  courrier  electronique  et  j'effectuerai  la
  correction.

  99..22..  TTrraadduuccttiioonn

  A l'heure ou j'ecris ces lignes, je ne connais pas de traduction de ce
  document. Si vous en realisez une, s'il vous plait dites-le  moi.   Je
  suis  disponible pour toute aide concernant l'explication du texte, je
  serai tres content d'y repondre.

  Note du traducteur : CCooccoorriiccoo !! La version francaise est  la  premiere
  traduction de ce document.

  99..33..  CCoonnttaaccttss

  Tout  contact  est le bienvenu. Envoyez-moi un courrier electronique a
  l'adresse suivante : dan@detached.demon.co.uk.  Ma clef  publique  PGP
  (ID     5F263625)     est     disponible    sur    mes    pages    WWW
  <http://ftp.linux.org.uk/~barlow/>,   Si   vous    souhaitez    rendre
  confidentiel certains messages.

  99..44..  CCooppyyrriigghhtt

  Toutes les remarques appartiennent a leurs auteurs respectifs.

  Ce    document    est    copyrighte    (C)    1996    Daniel    Barlow
  <dan@detached.demon.co.uk>. Il peut etre  reproduit  et  distribue  en
  partie  ou  entierement, sur tout support physique ou electronique, du
  moment  ou  ce  copyright  se  trouve  sur  toute   les   copies.   La
  redistribution  commerciale  est  autorisee  et  encouragee. Toutefois
  l'auteur de ce document doit etre  mis  au  courant  de  ce  genre  de
  distributions.

  Toute  traduction,  adaptation,  ou bien tout travail incorporant tout
  document HowTo Linux doit posseder ce  copyright.  De  cette  maniere,
  vous  ne  pouvez  pas  imposer  de restriction a la distribution de ce
  document.  Des exceptions peuvent etre eventuellement  accordees  sous
  certaines  conditions  : contactez le coordinateur des HowTo's Linux a
  l'adresse donnee ci-dessous.

  En resume, nous souhaitons voir diffuser l'information de  la  maniere
  la  plus large qui soit. Toutefois, nous souhaitons garder la maitrise
  de  ces  documents  et  nous  aimerions  etre  consultes  avant  toute
  diffusion des HowTo's.

  Si  vous  avez  des  questions, vous pouvez contacter Greg Hankins, le
  coordinateur des HowTo Linux HOWTO a l'adresse electronique suivante :
  gregh@sunsite.unc.edu

  1100..  IInnddeexx

  Les entrees de cet index sont triees dans l'ordre alphabetique.

  +o  -fwritable-strings ``39'', ``56''

  +o  /lib/cpp ``16''

  +o  a.out ``1''

  +o  ar ``10''

  +o  as ``8''

  +o  <asm/*.h> ``19''

  +o  atoi() ``40''

  +o  atol() ``41''

  +o  executables trop gros ``63'', ``65'', ``77''

  +o  chewing gum ``3''

  +o  cos() ``68''

  +o  deboguer ``59''

  +o  divers ``72''

  +o  dlopen() ``82''

  +o  dlsym() ``83''

  +o  documentation ``4''

  +o  EINTR ``52''

  +o  elf ``0'', ``71''

  +o  execl() ``57''

  +o  fcntl ``47''

  +o  FD_CLR ``44''

  +o  FD_ISSET ``45''

  +o  FD_SET ``43''

  +o  FD_ZERO ``46''

  +o  fichier ``2''

  +o  <float.h> ``20''

  +o  gcc ``6''

  +o  gcc -fomit-frame-pointer ``61''

  +o  gcc -g ``60''

  +o  gcc -v ``14''

  +o  gcc, bogues ``15'', ``28'', ``29'', ``84''

  +o  gcc, options de compilation ``13'', ``25'', ``26''

  +o  gdb ``64''

  +o  fichiers d'en-tete ``17''

  +o  appels systemes interrompus ``51''

  +o  ld ``9''

  +o  LD_* : variables d'environnement ``80''

  +o  ldd ``81''

  +o  libc ``7''

  +o  libg.a ``62''

  +o  libgcc ``79''

  +o  <limits.h> ``21''

  +o  lint ``58''

  +o  <linux/*.h> ``18''

  +o  <math.h> ``70''

  +o  maths ``69''

  +o  mktemp() ``55''

  +o  numero de version ``12'', ``74''

  +o  optimisation ``27''

  +o  pages de manuel ``5''

  +o  QMAGIC ``76''

  +o  segmentation fault ``30'', ``54''

  +o  segmentation fault, in GCC ``33''

  +o  select() ``50''

  +o  SIGBUS ``34''

  +o  SIGEMT ``35''

  +o  SIGIOT ``36''

  +o  SIGSEGV ``31'', ``53''

  +o  SIGSEGV, in gcc ``32''

  +o  SIGSYS ``38''

  +o  SIGTRAP ``37''

  +o  sin() ``67''

  +o  soname ``73''

  +o  sprintf() ``42''

  +o  binaires linkes statiquement ``66'', ``78''

  +o  <stdarg.h> ``23''

  +o  <stddef.h> ``24''

  +o  strings ``11''

  +o  <sys/time.h> ``48''

  +o  <unistd.h> ``49''

  +o  <varargs.h> ``22''

  +o  ZMAGIC ``75''

