(Courriels de diversion: <demilitarisant@revolvers-ethnies.com> <fiance@fripon-etudiez.com> <potence@plusieurs-pechez.com> <renfrogne@deferlons-vieillissiez.com> <haïront@ligotes-libertines.com> <emetteurs@batteurs-faufilerons.com> <theoriserais@arriere-grand-pere-foirer.com> <recrire@regonfla-abjurer.com> <moussaillons@regretteront-berca.com> <stresse@eloignant-bâclons.com> )
Le Fri, 4 Oct 2002 09:00:29 +0200 Jean-Michel OLTRA <jm.oltra@libertysurf.fr> me disait que : > On Thursday 03 Oct 2002, georges favre wrote: > > > Bref je ne vois pas comment gcc sait interpréter l'option -lm. > > Ben, c'est qu'il est malin et qu'il sait que lm veut dire libm. Et par > conséquent il va le chercher là où il sait aussi où se trouvent les libs > (les fichiers .so = shared object). Typiquement /usr/lib mais aussi > ailleurs, dans les paths renseignés dans le fichier /etc/ld.so.conf par > exemple. En fait c'est l'éditeur de lien qui est chargé de cette > besogne. > Si d'aventure il ne trouvait pas la lib il faudrait indiquer sur la > ligne de commande (ou dans le Makefile) -L/chemin/vers/dossier en plus, > où dossier contient la susdite lib. > Pour en savoir plus il faudrait que d'autres gourous de gcc se mèlent du > thread ! Bon je suis pas (aque) guru (guru!) mais je voulais juste confirmer qu'une fois que la compilation a eu lieu, l'éditeur de Lien (comme le dit JM) prend la reléve et colle tous les objets au sein d'un même fichier binaire au format ELF. Ce format ELF contient, entre autres, des informations relatives au sections du programme (text,data, bss) mais aussi des informations relatives au chargement des bibliothéques dynamiques de fonctions. Donc pour être construit ld doit savoir où aller chercher les bibliothéques dynamiques afin de _résoudre_ les symboles (variables et fonctions) non résolus lors du "collage" de tous les fichiers objets... Comme le dit JM, ld s'appuie sur le fichier /etc/ld.so.conf qui contient la liste des chemins d'accés aux libs (en fait des répertoires quans lesquels ces libs sont stockées) ainsi que d'une variable d'environnement qui peut être positionnée comme bon nous semble et dont le nom est LD_LIBRARY_PATH. Cette variable est comme le path : une succession de répertoires séparés par des :. Ces répertoires doivent contenir (normalement) des fichiers .so. Parallélement à celà on peut spécifier dans la ligne de commande de GCC des option pour l'éditeur de lien (ld). Un de ces paramétres -L identifie un chemin (et un seul si on en veut plusieurs il faut mettre plusieurs -L <chemin>) permettant d'accéder aux bibliothéques. -l est aussi une autre option qui permet de dire à ld de lier le code objet à une bibliothéque dynamique. La résolution se fait semble-t-il de la manière suivante : lorsqu'on lance ldconfig -v, le cache est mis à jour (ld.so.cache). Ce cache contient la liste des bibliothéques avec leur localisation ainsi qu'éventuellement des liens précisant leur version. ld connait ainsi le mapping de ses librairies et saura laquelle choisir. Lorsque l'on invoque le lien avec une librairie avec -ltoto ld va ouvrir le cache et chercher libtoto.so.* dans les chaines (voir ldconfig -v). Si l'option -L est passée ou que la variable d'environnement LD_LIBRARY_PATH est positionnée et que le cache ne contient pas la bibliothéque toto, le répertoire pointé par -L (resp. la variable LD_LIBRARY_PATH) sera lu et ld essaiera de trouver une éventuelle bibliothéque toto se trouvant dans les répertoires ainsi définis. Lorsqu'il trouve cette chaine dans la liste du cache ou dans les noms des fichiers des répertoires définis, il récupére le lien associé (libtoto.so.2.0.1 par exemple) et lie le programme avec. Je pense que Marc pourrait nous en dire plus sur la chose... N'est il pas? -- Jean-Christophe ARNU --------------------------------------------------------------------- Aide sur la liste: <URL:mailto:linux-31-help@CULTe.org>Le CULTe sur le web: <URL:http://www.CULTe.org/>