On Thursday 25 September 2008 21:51:38 MALET Jean-Luc wrote:
> Benoit Peccatte wrote:
> > 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
Non, c'est le .so qui a moins d'infos. C'est lui qui est stripé et lié
statiquement (aux .o du source s'entend). Et sinon oui il reste les
information sur les fonctions publiques nécessaires à la liaison et non je ne
sais pas pourquoi gcc ne sait pas faire statiquemnt ce qu'il fait
dynamiquement.
> 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....
Ça lie dinamiquement le .so
> > 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...
Tant qu'on n'arrive pas a extraire une versionstatique ...
Bon je me suis documenté, je n'ai pas trouvé de moyen de l'extraire, et la
mailing-list bsd dit que ce n'est pas possible. Parmi les outils les plus
probables : nm, ld, objcopy, readelf
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 ***
