Merci à Plasmatic d'avoir posté, dans une des listes de diffusion, le texte sur lequel cette partie est principalement fondée.
Lorsque l'on crée (compile) un programme, plutôt que d'avoir à réécrire l'ensemble des fonctions nécessaires à l'accès au noyau, au matériel, aux fichiers, etc. on récupère toutes ces fonctions de base dans des bibliothèques. glibc, que l'on installera plus tard, est une des principales bibliothèques, qui contient le code pour toutes les fonctions de base nécessaires aux programmes, telles que l'accès aux fichiers, l'affichage d'informations à l'écran, et les comptes-rendus aux utilisateurs. A la compilation du programme, ces bibliothèques sont liées au nouveau programme, de façon à ce qu'il puisse utiliser toutes les fonctions contenues dans les bibliothèques.
Cependant, ces bibliothèques peuvent être assez volumineuses (par exemple, libc.a approche régulièrement les 2,5Mo), vous ne voudrez sans doute pas dupliquer chaque bibliothèque liée à votre programme. Imaginez que vous ayez une commande simple comme ls liée avec une bibliothèque de 2,5Mo! Au lieu de fusionner la bibliothèque et le programme, ce qui correspond à une édition de liens statique, mieux vaut la laisser dans un fichier indépendant et ne la charger qu'en cas de besoin. C'est cette édition de liens dynamiques qui permet de charger et décharger dynamiquement une bibliothèque selon les besoins du programme.
Nous avons maintenant un fichier de 1Ko et un de 2.5Mo, mais somme toute nous n'avons pas économisé d'espace mémoire (excepté peut-être en mémoire vive jusqu'à ce que l'on utilise la bibliothèque). L'avantage REEL de l'édition de liens dynamiques est qu'il nous suffit d'une seule copie de cette bibliothèque. Si ls et rmutilisent tous deux la même bibliothèque, ils n'ont pas besoin de deux copies de cette bibliothèque, alors qu'ils peuvent tous les deux accéder au code d'un seul et même fichier. Même en mémoire, les deux programmes se partagent le même code, plutôt que de le dupliquer en mémoire. Du coup, nous n'économisons pas seulement l'espace disque, mais aussi la mémoire vive si précieuse.
Si l'édition de liens dynamiques a tous ces avantages, pourquoi utiliser alors exclusivement l'édition de liens statiques ? Et bien, c'est parce que lorsque vous exécuterez chroot dans votre flambant neuf (mais plutôt incomplet) environnement LFS, ces bibliothèques dynamiques ne seront pas disponibles car elles se situeront dans votre ancienne arborescence de répertoires (/usr/lib par exemple) qui ne sera pas accessible depuis votre racine LFS ($LFS).
Ainsi, pour que vos nouveaux programmes fonctionnent dans l'environnement chroot vous devrez être sûr que les bibliothèques soient liées statiquement lorsque vous les compilerez, ce qui explique les options --enable-static-link, --disable-shared, et -static utilisées tout au long du chapitre 5. Au Chapitre 6, la première chose que nous ferons sera la création de la principale bibliothèque du système, glibc. Cela fait, nous commencerons à recréer tous les programmes étudiés au chapitre 5, mais en les liant dynamiquement cette fois, de façon à profiter du gain d'espace proposé par cette méthode.
Et maintenant vous savez pourquoi utiliser cette mystérieuse option -static. Si vous essayer de ne pas l'utiliser, vous verrez très rapidement ce qui arrivera lors de l'exécution du chroot dans votre nouveau et imparfait système LFS.
Si vous voulez en savoir plus sur l'édition de liens dynamiques, consultez un ouvrage ou un site web sur la programmation, plus spéciallement consacré à Linux.