Bibliothèques : statiques ou partagées ?

Bibliothèques : statiques ou partagées ?

À l'origine les bibliothèques çtaient simplement une archive de routines, à partir de laquelle on extrayait ou on 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 plateformes Linux, nous avons 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 certaines formes de systèmes de secours minimaux, 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'un sauvetage. Les systèmes de fichiers journalisés réduisent également la probabilité de ce genre de problème.

Les développeurs, au moins pendant qu'ils développent, préfèrent souvent utiliser les versions statiques des bibliothèques auxquelles ils lient leur code.

À plusieurs endroits du livre, des paramètres de configure tels que --disable-static sont utilisés, et à d'autres endroits, vous avez la possibilité d'utiliser les versions du système des bibliothèques plutôt que les versions fournies par un autre paquet. 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 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 svoir les outils 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 connaitrez pas les programmes qu'il faut recompiler.

La plupart des bibliothèques sont partagées, mais faites quelque chose de peu commun, par exemple si vous déplacez une bibliothèque partagée dans /lib et si vous cassez en plus le lien symbolique .so dans /usr/lib, mais si vous y laissez la bibliothèque statique, la bibliothèque sera liée, de façon transparente, aux programmes qui en ont besoin.

Une manière d'identifier si une bibliothèque statique est utilisée est 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 partout où vous installez, puis soit déplacez-les dans un autre répertoire de sorte que l'éditeur de liens ne les trouve plus, soit 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 noter 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, exigé par GnuTLS-3.0.19 mais lié également à des paquets qui l'utilisaient, 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 autonomes ne posent pas problème - si le paquet doit être reconstruit pour corriger un bogue ou une faille de sécurité, rien de plus ne s'y liera.

Quand BLFS indique des bibliothèques Système, cela signifie les versions partagées. Certains paquets tels pue Firefox-16.0.1 et GPL-Ghostscript-9.06 incluent beaucoup d'autres bibliothèques. Quand elles s'y relient, elles le font de manière statique, donc cela également grossit 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, décider d'utiliser les bibliothèques du système est facile. D'autres fois il se peut que vous deviez modifier la version du système (c'est le cas pour libpng-1.5.13 si on l'utilise pour Firefox-16.0.1). En outre, un paquet qui contient une ancienne bibliothèque ne peut plus se lier à la version actuelle, mais il peut se lier à une version moins ancienne : en général, le livre 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 ces 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 : http://wiki.linuxfromscratch.org/blfs/wiki/libraries