Benoit Peccatte wrote:
On Wednesday 24 September 2008 18:37:05 jean-luc malet wrote:
> 2008/9/24 Benoit Peccatte <[EMAIL PROTECTED]>
> > Hé non car comme tu l'as dit plus haut, un .a n'est qu'une collection
> > d'objets
> > donc ça n'a pas le même format.
>
> un format est un format... franchement lorsque le linker va ouvrir un .a
> (qui est une archive ar, donc pas loin d'un vulgaire zip) et rechercher
> dans la collection d'objets (elf qui plus est!) lequel correspond à
l'appel
> de fonction, et lorsqu'il va ouvrir un elf qui est un jeu d'objets
> concaténés avec un header qui permet de savoir ce qui manque et où
trouver
> quoi afin de faire la résolution des noms au runtime... pour moi c'est
> kiffkiff... pour tirer le résonnement à l'extrême, qu'est qui empêche le
> linker de faire la résolution qui est effectuée au runtime au linktime?
> s'il est capable de le faire au moment où cela doit s'executer,
c'est alors
> faisable avant l'execution.... le conteneur change pas le contenu....
Si le contenu change car il est lui même lié statiquement. De plus il
est en général stripé, c'est à dire qu'un certain nombre de symboles
ont disparu.
ben déjà s'il est strippé et lié statiquement (enfin pas tout car si tu
oublie de mettre les bonnes libs sur ta ligne de link... tu auras un
zoli message disant "unresolved symbols") il a moins d'infos que la .so
tu es d'accord? donc rien n'empêcherai le linker au moment du link de
faire la résolution des symbols.... d'ailleurs je me demande ce que cela
fait si tu n'utilise pas -lxxxx mais que tu fais un g++ mon.cpp -o
monprog /usr/lib/libxxxx.so....... /usr/lib/libxxxx.so est un elf comme
les .o.... je testerai lorsque j'aurais un peu de temps....
> > Sinon, tu obtiendra un bien meilleur résultat en disant au compilateur
> > (et pas
> > seulement au linker) que tu fais un exécutable statique, remplace
> > -Wl,--static
> > par --static.
>
> cela je ne le pense pas, car le compilateur n'en a rien à cirer avant le
> linktime du static. les objets créés sont tous relogeables et
contiennent
> tous les symboles nécessaires à la résolution de nom (sinon aucun
linkage
> avec aucune librairie voir aucun des objets généré n'est possible).
Celui
> qui est en charge de mette tout ensemble c'est le linker, et pas le
> compilateur qui va générer les objets, le compilateur doit donc
fournir des
> objets qui marchent quelque soit le linker utilisé après, à l'extrême on
> peu générer l'ensemble des .o (sans le --static) et après les lier
avec ld
> --static et cela marche sans aucun pb, sauf qu'il semblerait que ld avec
> l'option --static n'ira chercher que les .a et vu que j'ai une lib
> uniquement en .so et pas en .a.....
Homme de peu de foi, tu n'as même pas essayé. C'est le compilateur qui
appelle le linker et c'est lui qui choisit les paramètres à lui passer
(comme parexemple d'utiliser la libc que tu ne demande pas). Le fait
de lui passer -static va entre autre lui dire de ne pas charger les
bibliothèques qui ne fonctionnent qu'avec du chargement dynamique
comme c'est le cas pour libgcc_s.so justement.
Après rien ne t'empêche d'appeler toi-même le linker avec tous les
paramètres pour mieux en maitriser le processus.
hummm je m'incline, un petit coup de g++ -v -static m'indique que
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/crtend.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/../../../../lib64/crtn.o sont
fournis au lieu d'une lib en .a.... va savoir pourquoi ils préfèrent
avoir des objets plutot qu'une lib statique....
ok j'admets mon peu de foi ;)
> > > je ne trouve nul pas les options à donner pour que le linker
fasse le
> > > linkage avec la lib dynamique mais non pas au runtime (comportement
> > > d'une lib dynamique) mais au linktime... en gros qu'il fasse ce
qu'il
> > > fait avec une librarie static ".a" mais avec une librarie dynamique
> > > ".so"
> >
> > Je ne saisis pas l'intérêt, il te faut simplement le .a lequel se
trouve
> > en général dans le paquet -dev correspondant à la bibliothèque
dynamique.
> > Le .a
> > sera alors intégralement dans l'exécutable et tu n'en auras plus
besoin
> > ensuite.
>
> question... tu fais quoi lorsque le "vendeur" de la librairie ne fournis
> qu'un .so? de même si tu fais beaucoup de dev (ce qui est mon cas) tu te
S'il ne te fournit qu'un .so c'est qu'il ne t'as pas fourni un kit de
développemnt complet et c'est son choix, et c'est toi qui l'a choisi.
> retrouves avec une pallanquée de .a qui sont en duplicata avec les
.so...
> c'est de la perte de place alors que techniquement parlant faire la
> résolution de symboles en avance de phase (ie à la compilation et pas au
> run time) est tout à fait faisable (on peut même faire la résolution
> dynamique avant pour accélérer le charchement des exécutables)
Oui oui, l'outil prelink qui fait ça est connu pour accélérer le
chargement de openoffice.
prelink? humm j'avais perdu le nom... serait amusant d'avoir un outil de
type full linkage.... qui prendrait un executable dynamique, les libs
dynamiques et hop ferait la résolution de noms pour tout mettre dans un
seul binaire...
merci en tout cas...
JL
Diffusez cette liste aupres de vos relations :)
Linux Azur : http://linux-azur.org
L'auteur du post est responsable de ses �crits !
*** Pas de message SMS, HTML ni de PJ SVP ***
