La GlibC est la bibliothèque C du projet GNU, disponible sous licence LGPL, ce qui signifie que l'on peut l'intégrer dans un projet propriétaire. Presque tous les projets disponibles sous Linux l'utilisent, elle possède donc la compatibilité la plus importante de toutes les bibliothèque C !
L'installation de la GlibC est l'objet du chapitre 3. Il faut savoir que l'une des principales contraintes est qu'il faut compiler les outils de développement (Binutils, GCC) avec son support, ce qui est assez long et fastidieux.
Le tableau suivant présente les résultats obtenus, la valeur entre parenthèses précise la taille occupée par les bibliothèques partagées :
Tableau A.6. Evaluation de la GlibC
GlibC 2.3.5 | en statique | en dynamique |
---|---|---|
BusyBox par défaut | 908 Ko | 1684 Ko (1396 Ko) |
BusyBox complet | 1880 Ko | 2952 Ko (2124 Ko) |
Ash | 612 Ko | 1520 Ko (1396 Ko) |
bibliothèque | 9636 Ko | 2732 Ko |
Ash est un petit interpréteur de commandes[28] compatible avec les scripts Bash. Etant donné qu'il se compile avec presque toutes les bibliothèques C, il nous servira de point de comparaison.
La ligne nommée "bibliothèque" présente la taille occupée par les fichier .a
(statique) et les fichiers .so
(dynamique). Seuls ces derniers nous intéressent vraiment, puisqu'ils sont susceptibles d'être embarqués dans le système, la taille des bibliothèques statiques est uniquement donnée à titre de comparaison sur la taille du code.
Comme nous pouvons le constater, les binaires liés à la GlibC font généralement quelques méga-octets. Même si la GlibC est la bibliothèque C qui possède la plus grande compatibilité et le plus grand nombre de fonctionnalités, il est fortement conseillé de ne l'utiliser que s'il n'y a pas d'autres solutions. En effet, si on souhaite l'embarquer dans un système muni de 16 Mo de mémoire vive, entre 10\% et 15\% seront utilisés uniquement pour le répertoire /lib
du RAMDisk, et c'est sans parler de la mémoire utilisée par les processus.
Le tableau suivant présente les résultats obtenus, la valeur entre parenthèses précise la taille prise par les bibliothèques partagées :
Tableau A.7. Evaluation de µClibC
µClibC 0.9.27 | en statique | en dynamique |
---|---|---|
BusyBox par défaut | 388 Ko | 588 Ko (296 Ko) |
BusyBox complet | 996 Ko | 1176 Ko (348 Ko) |
Ash | 164 Ko | 424 Ko (296 Ko) |
bibliothèque | 1132 Ko | 460 Ko |
Comme nous pouvons le constater, les binaires liés à la µClibC sont généralement trois fois plus petit que ceux liés avec la GlibC, sans pour autant perdre en fonctionnalité. La compilation de Ash a nécessité une petite modification, mais il semblerait que ce soit plus un problème avec le compilateur qu'avec la bibliothèque C (le GCC utilisé avec la GlibC accepte une syntaxe plus souple que celui utilisé avec la µClibC).
Pour compiler un programme avec la µClibC, il suffit d'utiliser la commande powerpc-linux-uclibc-gcc à la place de powerpc-405-linux-gnu-gcc. J'ai testé sans aucun problème la re-compilation des bibliothèques NCurses et Zlib, ainsi que la suite d'outils Heirloom (avec quelques modifications mineures). Sachant que la µClibC est utilisée dans un très grand nombre de projets industriels, nous pouvons l'utiliser dans un environnement de production. Malheureusement, la µClibC ne supporte que le C, et il n'y a donc pas de bibliothèque C++.
Newlib est une bibliothèque C spécialement conçue pour le domaine de l'embarqué, elle est diffusée sous plusieurs licences, qui dépendent de la cible et des fonctionnalités. Il est donc préférable de bien les lire avant d'utiliser la Newlib dans un projet commercial.
D'après la documentation de Newlib 1.13.0, cette bibliothèque C peut être compilée en tant que bibliothèque partagée seulement lorsque la cible et l'hôte sont identiques (c'est à dire lorsqu'on ne fait pas de compilation croisée). Il semblerait même que cela soit uniquement disponible avec la version x86... Dans les faits, je n'ai effectivement pas pu compiler la Newlib comme bibliothèque partagée (pour PowerPC), et la version statique (pour PowerPC) n'a jamais voulu fonctionner correctement avec mes tests.
J'ai alors essayé avec la version x86, mais là encore j'ai rencontré trop de problèmes lors de son installation et de son utilisation pour pouvoir faire correctement des tests. Malgré tous mes efforts, les documentations ne sont pas suffisamment à jour et pas suffisamment détaillées pour réussir à obtenir quelque chose (et c'est pas faute d'avoir insisté). En fait, il semblerait qu'il faille respecter scrupuleusement les documentations, dans le sens où si on essaye de compiler la Newlib avec d'autre Binutils (et GCC) que ceux qui sont indiqués, cela pose de gros problèmes.
La DietLibC a été conçue par l'auteur EmbUtils dans le but de fournir une bibliothèque C extrêmement petite et complète, elle est disponible sous GPL, ce qui signifie que tout projet basé sur elle passe alors sous licence libre. La DietLibC n'est pas compatible avec la GlibC, ce qui veut dire qu'il faut souvent modifier les sources des programmes pour qu'ils fonctionnent correctement.
Pour changer le répertoire d'installation, il suffit de modifier la ligne suivante du fichier Makefile
:
prefix?=/opt/diet
Enfin, il suffit de lancer les commandes suivantes pour installer la DietLibC:
bash# make bash# make dyn bash# make install
Le tableau suivant présente les résultats obtenus :
Je ne suis pas parvenu à recompiler un projet qui n'ait pas été spécialement conçu pour la DietLibC. Cela ne veut pas dire qu'elle n'est pas complète, mais seulement qu'elle n'est absolument pas compatible avec les projets faits pour la GlibC. La DietLibC possède tout de même des bibliothèques de fonctions mathématiques et un support des "Posix Threads". Il existe même une distribution Linux basée sur cette dernière : DietLinux.
On pourrait envisager d'utiliser la DietLibC pour des projets industriels ayant de fortes contraintes d'espace mémoire. C'est en fait l'objectif de cette bibliothèque, au détriment de la compatibilité. Cependant, le support des bibliothèques partagées n'en est encore qu'au stade du test, ce qui rend celles-ci non utilisables dans un environnement de production.
DietLibC est très facile à utiliser puisqu'il suffit de rajouter la commande diet devant les appels à gcc, celle-ci s'occupant d'encapsuler le compilateur. Malheureusement, on ne peut pas utiliser la DietLibC dans un environnement de compilation croisé, car la commande diet sera compilée pour la cible et non pour l'hôte.
La KlibC se veut être un sous ensemble minimaliste de la bibliothèque C standard. Elle est surtout utilisée pour créer des RAMDisks d'initialisation et est conçue dans l'optique d'être la plus petite possible, et ce au détriment de la vitesse s'il le faut ! La KlibC est disponible sous licence GPL et BSD, ce qui signifie que tout projet qui se base sur les parties GPL passera sous licence libre. Il faut donc bien faire attention. La KlibC est encore jeune, et il manque encore beaucoup de fonctionnalités, mais elle est très active (elle fait même partie des projets de kernel.org). Cependant, il ne faut pas espérer qu'elle devienne aussi complète que µClibC... Comme pour la DietLibC, la KlibC utilise un encapsuleur, il n'est donc pas nécessaire de recompiler toute la chaîne de développement GNU. Il est même possible d'utiliser cet encapsuleur dans un environnement de compilation croisée, contrairement à celui de la DietLibC.
Nous avons déjà vu comment installer la KlibC lors de l'installation du Système K, à la section A.2.4. Pour compiler un programme avec la KlibC, il suffit d'utiliser powerpc-405-linux-gnu-klcc à la place de powerpc-405-linux-gnu-gcc.
Le tableau suivant présente les résultats obtenus, la valeur entre parenthèses précise la taille prise par la bibliothèque partagée :
Tableau A.9. Evaluation de KlibC
KlibC 1.0 | en statique | en dynamique |
---|---|---|
Ash (modifié) | 112 Ko | 136 Ko (36 Ko) |
bibliothèque | 260 Ko | 36 Ko |
On retrouve avec la KlibC le même problème qu'avec la DietLibC : elle est tellement optimisée en taille qu'elle n'est pas compatible avec les applications qui ne sont pas spécialement conçues pour. Mais pire encore, la KlibC ne possède pas d'autres bibliothèques comme celle des fonctions mathématiques ou celle des "Posix Threads".
Finalement, la KlibC est de loin la plus petite bibliothèque C, mais son manque de fonctionnalités et sa jeunesse font qu'on ne peut pas réellement l'utiliser dans un environnement de production.