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 et elles ont un nom de la forme libtoto.a sur les systèmes d'exploitation UNIX.
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 » (ou encore « dynamiques »)
et elles ont un nom de la forme libtoto.so. Une seule copie de la bibliothèque
est chargée dans la mémoire virtuelle et partagée par tous les
programmes qui appellent 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). De nos jours, la plupart des
gens utilisent une installation système alternative ou une clé USB
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.
À 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
surtout 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 libtoto.so.2.0 à libtoto.so.2.1. Le passage à libtoto.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 le
recompiler. Si vous connaissez les programmes liés à une
bibliothèque statique particulière, pas de problème. Mais en
général, vous ne saurez pas
quels programmes recompiler.
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
libtoto.a devienne par exemple
libtoto.a.hidden. Vous pouvez alors
restaurer temporairement une bibliothèque statique si nécessaire,
et identifier les paquets qui en ont besoin. Vous ne devriez pas le
faire sans réfléchir car de nombreuses bibliothèques n'existent
qu'en version statique. Par exemple, certaines bibliothèques des
paquets glibc et gcc devraient toujours être présentes sur le
système (libc_nonshared.a, libg.a,
libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a pour
glibc-2.36 et gcc-12.2).
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-115.2.0 et ghostscript-10.01.2 embarquent beaucoup d'autres bibliothèques dans leur arborescence de construction. 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.40 si on l'utilise pour Firefox-115.2.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 plus ancienne. Dans ce cas, BLFS utilisera généralement 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 celles et ceux du paquet et vous n'avez aucun autre paquet qui l'utilisera. Dans ces cas, vous pourriez décider d'utiliser la bibliothèque incluse même si vous préférez généralement utiliser les bibliothèques du système.