[TECH] Re: se lier statiquement avec une librarie dynamique
Je n'ai pas de solution mais une autre possiblité est juste de linker en dynamique avec un rpath pour indiquer ou trouver la librairie dynamique et la fournir à côté de l'exécutable dans l'environement chrooté. Lien en angalis (désolé ) http://www.cs.indiana.edu/~welu/notes/node11.html g++ -o main main.o -lfoo -L./ -Wl,-rpath=`pwd` Mes 2 cents. 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 ***
Re: se lier statiquement avec une librarie dynamique
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 -l mais que tu fais un g++ mon.cpp -o > monprog /usr/lib/lib.so... /usr/lib/lib.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 ***
Re: se lier statiquement avec une librarie dynamique
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 -l mais que tu fais un g++ mon.cpp -o monprog /usr/lib/lib.so... /usr/lib/lib.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...
Re: se lier statiquement avec une librarie dynamique
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. > > 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. > > > 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. 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 ***
Re: se lier statiquement avec une librarie dynamique
2008/9/24 Benoit Peccatte <[EMAIL PROTECTED]> > Selon jean-luc malet <[EMAIL PROTECTED]>: > > > j'ai un petit cgi Ã(c)crit en C++ qui marche bien en dynamique (donc sans > la > > prison de type chroot) > > je me suis dit "ben tu n'as qu'à le linker en static..." sitôt dit > sitôt > > fait... > > g++ mon.cpp -o mon.cgi -Wl,--static > > et là c'est le drame... la libgcc_s.so n'as pas de pendant en .a donc ld > se > > plaint de ne pas trouver -lgcc_s... bien. il cherche un .a? que ce > > passe-t-il si on fait un lien symbolique? ah maintenant il se plaint que > > c'est une librarie dynamique et pas une librarie statique > > 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 > > 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. l'exemple typique c'est que pour faire un .so (librarie dynamique) il te suffit de compiler tes sources pour avoir une collection de .o que tu link après avec ld (et pas gcc) en utilisant des options tels que -Bdynamic et -soname. tu n'as pas besoin de compiler de nouveau pour faire le .a : tu fais un ar de tes .o et un ranlib (optionel sous linux) dessus le .a bref les même objets on servis pour faire la lib dynamique ou la lib static et les objets ont été compilé une seule fois avec un seul jeu d'option (en général un vulgaire gcc -C -o toto.o toto.c) > > > > 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 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) JLM -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) "mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile!" - "Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre." Betty Reese http://www.grainesdechangement.com/citations.htm 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 ***
Re: se lier statiquement avec une librarie dynamique
On Wed, Sep 24, 2008 at 5:22 PM, <[EMAIL PROTECTED]> wrote: > Salut > > > je me suis dit "ben tu n'as qu'à le linker en static..." sitôt dit > > sitôt > > fait... > > g++ mon.cpp -o mon.cgi -Wl,--static > > et là c'est le drame... la libgcc_s.so n'as pas de pendant en .a donc ld > > se > > plaint de ne pas trouver -lgcc_s... bien. il cherche un .a? que ce > > passe-t-il si on fait un lien symbolique? ah maintenant il se plaint que > > c'est une librarie dynamique et pas une librarie statique > > T'as essaye -static-libgcc ? > > je pourais toujours essayer... mais mis à part recompiler le compiler je ne risque pas d'avoir de résultat probant vu que seul le .so est présent sur le système -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) "mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile!" - "Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre." Betty Reese http://www.grainesdechangement.com/citations.htm 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 ***
Re: se lier statiquement avec une librarie dynamique
Salut > je me suis dit "ben tu n'as qu'à le linker en static..." sitôt dit > sitôt > fait... > g++ mon.cpp -o mon.cgi -Wl,--static > et là c'est le drame... la libgcc_s.so n'as pas de pendant en .a donc ld > se > plaint de ne pas trouver -lgcc_s... bien. il cherche un .a? que ce > passe-t-il si on fait un lien symbolique? ah maintenant il se plaint que > c'est une librarie dynamique et pas une librarie statique T'as essaye -static-libgcc ? 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 ***
Re: se lier statiquement avec une librarie dynamique
Selon jean-luc malet <[EMAIL PROTECTED]>: > j'ai un petit cgi écrit en C++ qui marche bien en dynamique (donc sans la > prison de type chroot) > je me suis dit "ben tu n'as qu'à le linker en static..." sitôt dit sitôt > fait... > g++ mon.cpp -o mon.cgi -Wl,--static > et là c'est le drame... la libgcc_s.so n'as pas de pendant en .a donc ld se > plaint de ne pas trouver -lgcc_s... bien. il cherche un .a? que ce > passe-t-il si on fait un lien symbolique? ah maintenant il se plaint que > c'est une librarie dynamique et pas une librarie statique 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. 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. > 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. 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 ***
