Les premières bibliothèques étaient de simples archives de routines, à partir desquelles on extrayait et liait les routines nécessaires dans l'exécutable. On appelle cela des bibliothèques statiques (libfoo.a). Sur certains systèmes d'exploitation anciens, ce sont les seules qui sont disponibles.
Sur la plupart des plate-formes Linux, il y a aussi des bibliothèques partagées (libfoo.so) - une copie de la bibliothèque est chargée dans la mémoire virtuelle et partagée par tous les programmes qui appellent une de ses fonctions. C'est plus efficace en terme d'espace.
Autrefois, des programmes essentiels tels que le shell étaient
souvent liés de manière statique pour qu'il existe une forme de
système de secours minimal, même en cas de bibliothèques partagées
endommagées telles que libc.so (par exemple, déplacées dans
lost+found après un fsck consécutif à
une extinction brutale). Aujourd'hui, la plupart des gens utilisent
une installation système alternative ou un Live CD s'ils ont besoin
d'une récupération. Les systèmes de fichiers journalisés réduisent
également la probabilité de ce genre de problème.
Les développeurs préfèrent souvent utiliser les versions statiques des bibliothèques auxquelles ils lient leur code, au moins pendant qu'ils développent.
À plusieurs endroits du livre, des paramètres de configuration tels que --disable-static sont utilisés, et à d'autres endroits, la possibilité d'utiliser les versions du système des bibliothèques plutôt que les versions fournies par un autre paquet est abordée. Nous traitons cela pour simplifier les mises à jour des bibliothèques.
Si un paquet est lié à une bibliothèque dynamique, la mise à jour de la bibliothèque se fait automatiquement une fois que la nouvelle bibliothèque est installée et que le programme est (re)démarré (à condition que la version majeure de la bibliothèque reste inchangée, passant par exemple de libfoo.so.2.0 à libfoo.so.2.1. Le passage à libfoo.so.3 exigera une recompilation - utilisez ldd pour connaître les programmes qui utilisent l'ancienne version). Si un programme est lié à une bibliothèque statique, il faut toujours recompiler le programme. Si vous connaissez les programmes liés à une bibliothèque statique en particulier, pas de problème. Mais en général, vous ne saurez pas quels programmes recompiler.
La plupart des bibliothèques sont partagées, mais si vous faites
quelque chose de peu commun, par exemple si vous déplacez une
bibliothèque partagée dans /lib et
que vous cassez le lien symbolique .so
dans /usr/lib tout en laissant la
bibliothèque statique dans /lib, la
bibliothèque statique sera liée, de façon silencieuse, aux
programmes qui en ont besoin.
Une manière d'identifier si une bibliothèque statique est utilisée
est de s'en préoccuper à la fin de l'installation de chaque paquet.
Écrivez un script pour trouver toutes les bibliothèques statiques
dans /usr/lib ou bien là où vous
installez, puis déplacez-les dans un autre répertoire de sorte que
l'éditeur de liens ne les trouve plus ou renommez-les pour que
libfoo.a devienne par exemple libfoo.a.hidden. Vous pouvez alors
restaurer temporairement une bibliothèque statique si nécessaire,
et identifier les paquets qui en ont besoin. Vous pouvez choisir
d'exclure de glibc certaines bibliothèques statiques si vous faites
cela (libc_nonshared.a, libg.a, libieee.a,
libm.a, libpthread_nonshared.a, librpcsvc.a, libsupc++.a)
pour simplifier la compilation.
Si vous faites cela, il se peut que vous trouviez que plus de paquets que vous ne le pensiez utilisent une bibliothèque statique. C'était le cas avec nettle-2.4 dans sa configuration par défaut en statique seulement : il était requis par GnuTLS-3.0.19, mais aussi lié à des paquets qui utilisaient GnuTLS-3.0.19, tels que glib-networking-2.32.3.
De nombreux paquets mettent certaines de leurs fonctions courantes dans une bibliothèque qui n'est utilisée que par les programmes du paquet et qui, surtout, n'est pas installée en tant que bibliothèque autonome. Ces bibliothèques internes ne posent pas problème - si le paquet doit être reconstruit pour corriger un bogue ou une faille de sécurité, rien de plus n'y est lié.
Quand BLFS indique des bibliothèques système, cela signifie les versions partagées. Certains paquets tels que Firefox-102.1.0 et ghostscript-9.56.1 incluent beaucoup d'autres bibliothèques. Quand ils s'y lient, ils le font de manière statique, donc cela fait également grossir les programmes. La version incluse est souvent plus ancienne que la version utilisée dans le système, donc il se peut qu'elle comporte des bogues - parfois les développeurs prennent la peine de corriger les bogues dans les bibliothèques qu'ils incluent, mais pas toujours.
Parfois, il est facile de décider d'utiliser les bibliothèques du système. D'autres fois il se peut que vous deviez modifier la version du système (c'est le cas pour libpng-1.6.37 si on l'utilise pour Firefox-102.1.0). Parfois, un paquet contient une ancienne bibliothèque et ne peut plus se lier à la version actuelle, mais il peut se lier à une version moins ancienne. Dans ce cas, BLFS n'utilisera que la version incluse. Parfois, la bibliothèque incluse n'est plus développée de son côté, ou ses responsables en amont sont les mêmes que ceux du paquet et vous n'avez aucun autre paquet qui l'utilisera. Dans ce cas, vous pourriez décider d'utiliser la bibliothèque statique incluse même si vous préférez généralement utiliser les bibliothèques du système.
Notes utilisateur : https://wiki.linuxfromscratch.org/blfs/wiki/libraries
Last updated on