Premièrement, pour ton problème de MANPATH et LD_LIBRARY_PATH, peut-être que cpack (qui est fournit avec cmake) pourra t'aider. Pas sûr, perso je ne me suis encore jamais vraiment amusé à faire des archives pour diverses plate-formes...
Secundo, ceci n'est pas totalement vrai:
utilisent le fichier charger en mémoire de la glibc pour ses différentes fonctions, ce qui économise de la mémoire.
Les informations et calculs nécessaires à charger une bibliothèque liée dynamiquement (ou «partagée», les fameuses DLL de windows et .so sous linux) sont conséquentes.
Certains considèrent que la quantité d'informations et de calculs nécessaires au bon chargement d'un programme fait qu'au final, lier statiquement ferait en réalité gagner à la fois de l'espace mémoire (a minima mémoire persistante, je crois qu'ils parlaient aussi de RAM mais j'ai un doute) et calculs, du coup il y aurait une réelle perte de performances avec l'édition dynamique.
Il faudrait que j'arrive à retrouver la littérature sur laquelle j'étais tombé il y à quelques mois, les arguments étaient vraiment très intéressants, mais je me souviens que cette littérature m'a mené sur l'un des projets suckless: stali linux. Il y à une FAQ qui expose rapidement les idées de l'auteur sur ce sujet.
Personnellement, je ne suis pas totalement d'accord avec ces gens: lier dynamiquement du code utilisé par le système entier me semble plutôt pertinent, surtout pour les MaJ, bien qu'ils m'aient mis le doute (peut-être que je devrais tester sta.li, pour en avoir le cœur net?). Par contre, ce qui est quasi-certain, c'est que dans le cas de ta lib, qui ne sera pas utilisée par plus de 3-4 utilitaires, en faire une lib statique sera plus efficace.
Tu devrais tester: combien pèsent ta calculatrice liée dynamiquement + la lib, et combien pèse ta calculatrice liée statiquement? Pour ma part, j'avais fait quelques tests de mon côté: j'avais réimplémenté yes, pour être quasi égal au niveau des fonctionnalités avec la version GNU (le seul truc que je supportait pas, c'était les locales pour l'option --help...) et entre le statique sur la glibc et le dynamique, j'avais, de mémoire, 15% de gain. Ma version statique pesait aussi 10k de moins que le yes de gnu, sachant que GNU yes pèse... 31K. Ça donne à réfléchir, et pas qu'un peu.
Tout le monde ne parle que d'édition de liens dynamique, mais je crois que tout le monde fait juste le mouton de Panurge, sur ce point et sur bien d'autres. Peut-être que l'industrie logiciel s'encrasse dans ses idées reçues, au final...
# binaire d'install & économie supposée des lib partagées
Posté par freem . En réponse au message Une bibliothèque partagée (shared object, *.so) pour conversions et calculs mulitbases.. Évalué à 2. Dernière modification le 02 janvier 2015 à 12:38.
2 choses.
Premièrement, pour ton problème de MANPATH et LD_LIBRARY_PATH, peut-être que cpack (qui est fournit avec cmake) pourra t'aider. Pas sûr, perso je ne me suis encore jamais vraiment amusé à faire des archives pour diverses plate-formes...
Secundo, ceci n'est pas totalement vrai:
Les informations et calculs nécessaires à charger une bibliothèque liée dynamiquement (ou «partagée», les fameuses DLL de windows et .so sous linux) sont conséquentes.
Certains considèrent que la quantité d'informations et de calculs nécessaires au bon chargement d'un programme fait qu'au final, lier statiquement ferait en réalité gagner à la fois de l'espace mémoire (a minima mémoire persistante, je crois qu'ils parlaient aussi de RAM mais j'ai un doute) et calculs, du coup il y aurait une réelle perte de performances avec l'édition dynamique.
Il faudrait que j'arrive à retrouver la littérature sur laquelle j'étais tombé il y à quelques mois, les arguments étaient vraiment très intéressants, mais je me souviens que cette littérature m'a mené sur l'un des projets suckless: stali linux. Il y à une FAQ qui expose rapidement les idées de l'auteur sur ce sujet.
Personnellement, je ne suis pas totalement d'accord avec ces gens: lier dynamiquement du code utilisé par le système entier me semble plutôt pertinent, surtout pour les MaJ, bien qu'ils m'aient mis le doute (peut-être que je devrais tester sta.li, pour en avoir le cœur net?). Par contre, ce qui est quasi-certain, c'est que dans le cas de ta lib, qui ne sera pas utilisée par plus de 3-4 utilitaires, en faire une lib statique sera plus efficace.
Tu devrais tester: combien pèsent ta calculatrice liée dynamiquement + la lib, et combien pèse ta calculatrice liée statiquement? Pour ma part, j'avais fait quelques tests de mon côté: j'avais réimplémenté yes, pour être quasi égal au niveau des fonctionnalités avec la version GNU (le seul truc que je supportait pas, c'était les locales pour l'option --help...) et entre le statique sur la glibc et le dynamique, j'avais, de mémoire, 15% de gain. Ma version statique pesait aussi 10k de moins que le yes de gnu, sachant que GNU yes pèse... 31K. Ça donne à réfléchir, et pas qu'un peu.
Tout le monde ne parle que d'édition de liens dynamique, mais je crois que tout le monde fait juste le mouton de Panurge, sur ce point et sur bien d'autres. Peut-être que l'industrie logiciel s'encrasse dans ses idées reçues, au final...