Discussion :

[Christophe]

Bonsoir,

Je me pose une petite question sur la compilation statique.

Quand je compile avec 1 bibliothèques, est-ce la bibliothèque complète qui est liée à mon code ou juste les fonctions de celles-ci que j'utilise;

Merci pour votre réponse.

[Sve@r]

Salut
Question que je ne m'étais jamais posé. A priori je dirais qu'il s'agit de la bibliothèque intégrale. Je pense que c'est ça parce qu'une bibliothèque possède un index sur ses fonctions permettant un accès plus rapide. Et si c'était juste le code de la fonction qui était intégré dans l'exe, cela rendrait cet index inutile...

[Obsidian]

Bonjour,

Je me pose une petite question sur la compilation statique.

Quand je compile avec 1 bibliothèques, est-ce la bibliothèque complète qui est liée à mon code ou juste les fonctions de celles-ci que j'utilise; Merci pour votre réponse.

Oui, c'est la bibliothèque entière qui est liée à ton programme. Intégrer uniquement les ressources réellement utilisées serait beaucoup plus compliqué que ce que l'on pourrait imaginer car cela demanderait d'une part des infrastructures spéciales permettant d'isoler, d'extraire et de reloger les ressources exploitées (c'est-à-dire pratiquement recompiler la bibliothèque) et en outre, il serait algorithmiquement très compliqué d'affirmer de manière déterministe si le code va réellement être utilisé ou pas.

Même en considérant qu'à partir du moment où ton programme fait référence à une ressource de ta bibliothèque, celle-ci est considérée comme utilisée, il faudrait passer la bibliothèque elle-même aux rayons X pour affirmer que ses fonctions ne se feront pas références entre elles.

À dire vrai, le problème se pose également avec les bibliothèques dynamiques : à partir du moment où on en a besoin, celles-ci seront chargées intégralement en mémoire. Cela dit, le mécanisme de pagination qui gère en même temps la mémoire swap fera que seules les pages réellement lues à un instant donné seront chargées dans les faits. Dans le principe, ça semble être la solution au problème. En pratique, ce sera vrai mais seulement avec la granularité d'une page.

[jlliagre]

À dire vrai, le problème se pose également avec les bibliothèques dynamiques : à partir du moment où on en a besoin, celles-ci seront chargées intégralement en mémoire. Cela dit, le mécanisme de pagination qui gère en même temps la mémoire swap fera que seules les pages réellement lues à un instant donné seront chargées dans les faits. Dans le principe, ça semble être la solution au problème. En pratique, ce sera vrai mais seulement avec la granularité d'une page.

Au moins pour les systèmes de type Unix ou Linux, ce mécanisme de chargement en RAM uniquement des pages effectivement accédées est identique qu'il s'agisse de bibliothèques dynamiques ou statiques.

Il y a deux différences notables qui font que la compilation statique est une technique le plus souvent à oublier:

• si plusieurs programmes utilisent les mêmes bibliothèques, leur code ne sera chargé qu'une seule fois en RAM si dynamique mais autant de fois qu'il y a de programmes dans le cas de bibliothèques statiques d'ou gaspillage de mémoire et baisse des performances.

• un programme lié statiquement ne bénéficiera pas de corrections et améliorations apportées par les versions futures des bibliothèques qu'il utilise.

C'est la raison pour laquelle par exemple Solaris ne fournit plus de versions statique des bibliothèques système depuis 2005.

[Christophe]

Pour moi, l’intérêt de compiler en statique, c'est de ne pas avoir à installer de bibliothèques, au détriment effectivement de la possibilité de mise à jour, et que 2 logiciels statiques utilisant la même bibliothèque utiliseront plus de mémoire du coup.

C'est un choix à faire.

[ternel]

Théoriquement, la compilation statique supprime les blocs inutilisés, tandis que la bibliothèque dynamique est indépendante de toute application.

La notion même de bibliothèque n'existe plus une fois liée statiquement au code de l'exécutable.
Les fonctions qu'elle définit sont dans le binaire, exactement comme les autres.

[kwariz]

Bonjour,

Les bibliothèques statiques ne sont que des archives de fichiers objets et rien de plus. Pour créer une bibliothèque statique tu n'as d'ailleurs besoin que de tes fichiers objets et d'un archiveur. Sous linux par exemple l'archiveur utilisé est ar (il n'est à ma connaissance plus utilisé sauf pour créer des bibliothèques statiques). Il crée une archive à partir des fichiers objets et ajoute un index pour accéder rapidement au contenu (il y a longtemps un autre utilitaire ranlib construisait cet index, mais il est maintenant intégré à ar).
L'important dans la création d'une bibliothèque statique n'est pas tant sa création que la segmentation des fichiers objets. Imaginons que tu veuilles créer une bibliothèque statique libstat qui va proposer 3 fonctions : fct1, fct2, fc3. Supposons que fct1 se suffise à elle-même, et que fct2 appelle fct3.
Si tu définis les 3 fonctions dans un source bigsource.cqui donnera un objet bigsource.o alors lors de l'édition des liens il suffit que tu utilises une seule des trois des fonctions pour te retrouver avec le code des trois dans ton exécutable (bien que gcc par exemple permette aussi de faire de l'optimisation lors de l'édition des liens mais c'est plus difficile/délicat).
Si tu définis un source par fonction fct1.c, ... alors tu auras trois fichiers objets fct1.o, ... et lors de l'édition des liens seul le code des fonctions utilisées sera lié à ton exécutable, bien que cela dépende aussi des options de compilations. Si tu n'utilises que fct3 alors seul le code de fct3 sera lié, en revanche si tu utilises fct2 alors le code de fct2 et de fct3 seront liés.
Tout se passe exactement comme si tu n'utilisais pas de bibliothèque statique mais les objets qu'elle contient à la place.
Les détails précis dépendent de la chaîne de compilation utilisée.

Les bibliothèques dynamiques doivent contenir tout le code de tous les objets car on ne sait pas comment elles pourront être utilisées.
On peut lier dynamiquement, c'est-à-dire décider au moment de l''édition des liens que certaines parties de codes se trouveront ailleurs dans une bibliothèque dynamique, le loader de l'OS se débrouillera pour trouver tout ce qu'il faut.
On peut également charger à l'exécution une bibliothèque dynamique et y chercher du code qui sera exécuté par la suite (ce que font les plugins) mais là tout est à la charge de l'exécutable. Si je ne me trompe pas, toute la bibliothèque sera intégralement mappée en mémoire virtuelle dans les deux cas.
Les détails précis dépendent principalement de l'os.

[gangsoleil]

Il y a deux différences notables qui font que la compilation statique est une technique le plus souvent à oublier:

• si plusieurs programmes utilisent les mêmes bibliothèques, leur code ne sera chargé qu'une seule fois en RAM si dynamique mais autant de fois qu'il y a de programmes dans le cas de bibliothèques statiques d'ou gaspillage de mémoire et baisse des performances.

• un programme lié statiquement ne bénéficiera pas de corrections et améliorations apportées par les versions futures des bibliothèques qu'il utilise.

A l'inverse, dans certains cas, la compilation dynamique est a oublier :

• Probleme de mise a jour des versions : on ne compte plus les bibilotheques qui ne sont pas backward compatibles, et qui s'en foutent. Dans ce cas, un simple update de la bibliotheque, et ton programme ne fonctionne plus.
• Probleme des libs en matiere de securite : n'importe qui (ou presque) peut remplacer la lib dynamique par une version differente, changeant le comportement. C'est d'ailleurs pour cette raison qu'il n'y a pas (ou qu'il ne devrait pas y avoir) de lib incluant des fonctions de securite (login, cryptographie, ...)

[ternel]

ah? et libcrypto, libssl et libssh, c'est quoi?

[Metalman]

C'est plus un problème de sécurité des libs et de l'environnement en général...

Mais ça n'est pas négligeable non plus comme argument en effet ! (imaginons un script online qui écrit dans les fichiers temporaire un .so/.dll, et force le navigateur à faire un export/setenv... tout peut arriver après !)

[Médinoc]

Probleme des libs en matiere de securite : n'importe qui (ou presque) peut remplacer la lib dynamique par une version differente, changeant le comportement.

Normalement sur un système bien configuré, il faut déjà être admin pour ça.

[ternel]

Pas forcément, il suffit de changer l'environnement pour changer le chemin de recherche de la lib. Ca a même un nom: lib spoofing

[jlliagre]

A l'inverse, dans certains cas, la compilation dynamique est a oublier :

• Probleme de mise a jour des versions : on ne compte plus les bibilotheques qui ne sont pas backward compatibles, et qui s'en foutent. Dans ce cas, un simple update de la bibliotheque, et ton programme ne fonctionne plus.

Les bibliothèques correctement développées sont versionnées pour résoudre ce problème.

• Probleme des libs en matiere de securite : n'importe qui (ou presque) peut remplacer la lib dynamique par une version differente, changeant le comportement. C'est d'ailleurs pour cette raison qu'il n'y a pas (ou qu'il ne devrait pas y avoir) de lib incluant des fonctions de securite (login, cryptographie, ...)

On ne doit pas vivre dans le même monde ... avoir des binaires liés statiquement à une bibliothèque contenant des failles de sécurité non patchées n'est pas franchement idéal et alors que seul quelqu'un disposant des privilèges requis peut remplacer une bibliothèque dynamique.