Bibliothèques : statiques ou partagées ?

Bibliothèques : statiques ou partagées ?

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.