Linux From Scratch compilé de façon croisée - Version GIT-20170803-Sparc64-Multilib

Chapitre 10. Installation des logiciels du système de base

10.7. Bibliothèques 32 Bit Glibc-2.25

Le paquet Glibc contient la bibliothèque C principale. Cette bibliothèque fournit toutes les routines basiques pour allouer de la mémoire, rechercher des répertoires, ouvrir et fermer des fichiers, les lire et les écrire, gérer les chaînes, faire correspondre des modèles, faire de l'arithmétique et ainsi de suite.

10.7.1. Installation de Glibc

[Note]

Note

Certains paquets en dehore de CLFS suggèrent d'installer GNU libiconv pour traduire les données d'un encodage en un autre. La page principale du projet (http://www.gnu.org/software/libiconv/) dit « Cette bibliothèque fournit une implémentation d'iconv(), à utiliser sur les système qui n'en ont pas, ou dont l'implémentation ne peut pas convertir de/vers l'Unicode. » Glibc fournit une implémentation d'iconv() et peut convertir depuis/vers l'Unicode, donc libiconv n'est pas requis sur un système CLFS.

À la fin de l'installation, le système de construction lancera un test de cohérence pour s'assurer que tout est installé correctement. Ce script lance ses tests en tentant de compiler des programmes de test avec certaines bibliothèques. Cependant il ne spécifie pas le chemin vers ld.so et notre chaîne d'outils est toujours configurée pour utiliser celui de /tools. L'ensemble de commandes suivantes forcera le script à utiliser le chemin complet du nouveau ld.so qui vient d'être installé : 

LINKER=$(readelf -l /tools/bin/bash | sed -n 's@.*interpret.*/tools\(.*\)]$@\1@p')
sed -i "s|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=${LINKER} -o|" \
  scripts/test-installation.pl
unset LINKER

Le système de construction de Glibc est auto-extractible et il s'installera parfaitement, même si le fichier specs du compilateur et l'éditeur de liens pointent vers /tools. Les specs et l'éditeur de liens ne peuvent pas être ajustés avant l'installation de Glibc, car les tests autoconf de Glibc donneraient de faux résultats, ce qui irait à l'encontre du but de faire une construction propre.

La documentation de Glibc recommande de construire Glibc dans un répertoire de construction dédié : 

mkdir -v ../glibc-build
cd ../glibc-build

Préparez la compilation de Glibc : 

CC="gcc ${BUILD32}" CXX="g++ ${BUILD32}" \
../glibc-2.25/configure \
    --prefix=/usr \
    --enable-kernel=3.12.0 \
    --libexecdir=/usr/lib/glibc \
    --host=${CLFS_TARGET32} \
    --enable-stack-protector=strong \
    --enable-obsolete-rpc

Voici la signification de la nouvelle option de configure :

--libexecdir=/usr/lib/glibc

Cela change l'emplacement des liens en dur vers l'utilitaire getconf de leur dossier /usr/libexec par défaut vers /usr/lib/glibc.

Compilez le paquet : 

make
[Important]

Important

À cause du rôle critque que joue Glibc dans un système fonctionnel, les développeurs de CLFS recommandent vivement de lancer la suite de tests.

Dans un environnement multilib, nous avons tendance à penser que la compilation pour ${CLFS_TARGET32} n'est pas une compilation croisée. Glibc considère que vous construisez pour un hôte différent, vous ne pourrez donc pas exécuter la suite de tests et par conséquent, vous n'avez pas besoins des fichiers de locales. Lorsque nous lançons les tests, beaucoup échouerons s'il manque les fichiers de locales. La commande sed suivante permet à ces tests de réussir : 

sed -i '/cross-compiling/s@ifeq@ifneq@g' ../glibc-2.25/localedata/Makefile

Utilisez la commande suivante pour lancer la suite de tests et récupérer les tests en échec : 

make check

La suite de tests de Glibc dépend grandement de certaines fonctionnalités du système hôte, en particulier du noyau. Les tests posix/annexc et conform/run-conformtest échouent normalement et vous devriez voir Error 1 (ignored) dans la sortie. En dehors de cela, la suite de tests de Glibc devrait réussir. Cependant, dans certaines circonstances, des échecs sont inévitables. Si un test échoue à cause d'un programme manquant (ou d'un lien symbolique manquant), ou d'une erreur de segmentation, vous verrez un code d'erreur supérieur à 127 et les détails se trouverent dans le journal. Plus couramment, les tests échoueront avec Error 2 — pour ceux-là, il faut vérifier le contenu des fichiers .out, par exemple posix/annexc.out. Voici une liste des problèmes les plus courants :

  • Les tests nptl/tst-clock2, nptl/tst-attr3, tst/tst-cputimer1 et rt/tst-cpuclock2 sont connus pour échouer. La raison n'est pas complètement comprise, mais des indications sont que des problèmes mineurs de temps peuvent déclencher ces échecs.

  • Les tests de math échouent parfois. Certains paramètres d'optimisation sont connus pour être en cause.

  • Si vous avez monté la partition CLFS avec l'option noatime, le test atime échouera. Comme indiqué dans Section 2.5, « Monter la nouvelle partition », n'utilisez pas l'option noatime lors de la construction de CLFS.

  • Lorsqu'ils sont lancés sur un matériel plus ancien et plus lent, certains tests peuvent échouer à cause du dépassement du temps limite. Modifier la commande make check pour indiquer TIMEOUTFACTOR permettrait d'éliminer ces erreurs (par exemple TIMEOUTFACTOR=16 make -k check).

  • posix/tst-getaddrinfo4 échouera toujours à cause de la connexion réseau manquante lorsque les tests sont lancés.

Bien que ce ne soit qu'un simple message, l'étape d'installation de Glibc se plaindra de l'absence de /etc/ld.so.conf. Supprimez ce message d'avertissement avec : 

touch /etc/ld.so.conf

Installez le paquet et supprimez des fichiers inutiles de /usr/include/rpcsvc : 

make install &&
rm -v /usr/include/rpcsvc/*.x

Des détails sur ce paquet se trouvent sur Section 10.8.5, « Contenu de Glibc. »