Guide de mise à jour de GCC pour GentooPourquoi faudrait-il que vous mettiez GCC à jour ? GCC ressemble fort aux autres paquets de votre système, il est juste plus critique. Vous devriez mettre GCC à jour au moment où une nouvelle version supprime un bogue qui vous ennuie, une nouvelle fonctionnalité dont vous avez besoin a été ajoutée ou si vous voulez simplement garder votre système à jour. Si les cas précédents ne vous correspondent pas, vous pouvez retarder votre mise à jour sans crainte tant que votre version de GCC est supportée par les développeurs de Gentoo. Si vous installez une nouvelle version majeure de GCC (par exemple de 3.3.6 à 3.4.5), le système ne basculera pas automatiquement vers la nouvelle version. Vous devrez exécuter des étapes supplémentaires durant la migration. Si vous décidez de ne pas exécuter ces étapes, Portage continuera à utiliser la version antérieure de votre compilateur jusqu'à ce que vous changiez d'avis ou supprimiez l'ancien compilateur de votre système. Les mises à jour mineures provoquent le basculement automatique vers la nouvelle version (par exemple de 3.4.5 vers 3.4.6). Ce guide documente les étapes nécessaires pour mettre à jour en douceur le compilateur utilisé par votre machine Gentoo. Une section spécifique est dédiée à la mise à jour de GCC depuis la version 3.3 à la 3.4 et aux problèmes liés à libstdc++. Une autre section spécifique vise les utilisateurs qui installent Gentoo à partir d'une image du stage3 après qu'une nouvelle version majeure ou mineure de GCC soit sortie.
2. Instructions générales de mise à jour
En général, les mises à jour qui corrigent des bogues, comme de GCC 3.3.5 à 3.3.6, devraient se passer sans risque – il suffit d'installer la nouvelle version, de modifier votre système afin d'utiliser le nouveau GCC et de recompiler le seul paquet affecté, libtool. Cependant, quelques mises à jour de GCC affectent la compatibilité des binaires ; dans ces cas, une recompilation des paquets concernés (ou même de la chaîne de compilation complète et du système) pourrait être requise. Souvenez-vous, nous avons dit que la mise à jour de GCC ne serait pas automatique. Il y a tout de même une exception : les mises à jour qui suppriment des bogues, comme de la version 3.3.5 à la 3.3.6, si vous n'utilisez pas l'option USE « multislot » qui autorise les deux versions à coexister sur un seul système. Multislot est désactivé par défaut, car il n'a pas grand intérêt pour les utilisateurs.
Pour être complètement sûr que votre système se trouve dans un état sain, vous devez recompiler la chaîne de compilation, puis world, afin de s'assurer que tous les paquets seront recompilés par le nouveau GCC.
Il est maintenant prudent de supprimer l'ancienne version de GCC. Si vous préférez, vous pouvez spécifier la version à désinstaller (comme d'habitude, remplacez =sys-devel/gcc-3.4* par la version à retirer) :
3. Mise à jour de la version 3.3 à la version 3.4 La mise à jour de GCC 3.3 à 3.4 n'est pas sans soucis, car l'ABI C++ a changé entre les deux versions. Il faut également s'occuper d'un problème qui va survenir avec la bibliothèque libstdc++.
Si vous mettez à jour de GCC 3.3 vers 3.4, vous avez le choix entre deux possibilités. La première méthode est la plus rapide et consiste en l'utilisation de l'outil revdep-rebuild du paquet gentoolkit, alors que la seconde recompile intégralement le système. Le système utilisera ainsi les nouvelles fonctionnalités de GCC. Le choix entre ces deux possibilités vous appartient. Dans la plupart des cas, la première méthode est suffisante. Si vous mettez à jour de GCC 3.3 vers 4.1, n'utilisez pas la méthode basée sur revdep-rebuild, mais faites plutôt une recompilation totale du système. Cette méthode requiert tout d'abord l'installation de gentoolkit si vous ne l'avez pas déjà. Nous pourrons alors mettre GCC à jour et passer de l'ancien au nouveau compilateur. Nous allons ensuite recompiler le paquet libtool afin de s'assurer que la chaîne de compilation est en parfait état.
Nous voulons maintenant voir quels paquets revdep-rebuild veut recompiler. Nous demanderons ensuite à revdep-rebuild de réinstaller ces paquets. Cela peut prendre du temps, soyez patient.
Pour permettre la compatibilité avec les anciennes applications binaires C++, sys-libs/libstdc++-v3 doit être installé sur votre système.
Cette méthode, bien que beaucoup plus longue, recompilera votre système entièrement afin de s'assurer que tout aura été reconstruit avec votre nouveau compilateur. C'est aussi une méthode moins risquée. En premier lieu, vous devrez mettre GCC et libtool à jour et ensuite passer de l'ancienne version du compilateur à la nouvelle.
Pour permettre la compatibilité avec les anciennes applications binaires C++, sys-libs/libstdc++-v3 doit être installé sur votre système.
Nous allons d'abord recompiler le système, ensuite le « world ». Cela va prendre du temps en fonction du nombre de paquets que vous avez installés, car votre chaîne de compilation entière et ses fichiers systèmes seront recompilés, suivis de chaque paquet de votre système, notamment la chaîne de compilation. Cela est nécessaire pour s'assurer que chaque paquet, y compris ceux de la chaîne de compilation elle-même, auront été compilés avec la nouvelle chaîne de compilation.
Supprimez maintenant votre ancienne version de GCC sans crainte :
4. Mise à jour de GCC à l'installation du système La mise à jour de GCC sur un système après l'installation d'une image de stage3 est assez simple. Un des avantages qu'ont les utilisateurs qui installent un nouveau système est qu'ils n'ont pas beaucoup de logiciels installés qui ont des liens avec les anciennes versions de GCC. L'exemple suivant sert pour la mise à jour de GCC 3.3 à 3.4. Certains passages seront différents si vous mettez à jour depuis une autre version de GCC. Par exemple, les noms des bibliothèques utilisées avec revdep-rebuild plus bas sont spécifiques à GCC 3.3, ainsi que le besoin d'installer libstdc++-v3. Si vous n'avez pas encore apporté de modification à votre système, il suffit de quelques étapes pour le mettre à jour vers une nouvelle version de GCC. Comme pour la mise à jour de GCC 3.3 vers 3.4, vous avez deux solutions. Cependant, il y a peu de différences entre les deux solutions. La première méthode est plus rapide et utilise l'outil revdep-rebuild du paquet gentoolkit, comme dans la procédure précédente. L'utilisation de revdep-rebuild n'entraîne la recompilation que pour les paquets qui ont un lien avec les bibliothèques de GCC, tandis que la seconde méthode entraîne la recompilation de tout le système et prend donc beaucoup plus de temps. Cette seconde méthode n'est jamais utile et est seulement documentée à des fins d'exhaustivité. Les premières étapes sont communes aux deux méthodes et doivent être accomplies dans tous les cas.
Pour permettre la compatibilité avec les anciennes applications binaires C++, sys-libs/libstdc++-v3 doit être installé sur votre système.
Cette méthode nécessite que vous installiez d'abord gentoolkit si vous ne l'avez pas déjà fait. Nous utiliserons revdep-rebuild pour rechercher les paquets installés à recompiler et les réinstaller.
Cette méthode, bien que plus lente, va recompiler tout le système pour s'assurer que tout a bien été compilé avec votre nouveau compilateur. Ce n'est pas nécessaire, mais c'est une solution valide si vous avez modifié les CFLAGS ou d'autres variables de /etc/make.conf qui ont un effet sur la compilation. Puisque nous accomplissons la mise à jour après une installation initiale, il est inutile de recompiler la cible world comme on devrait le faire pour une mise à jour d'un système déjà installé. Cependant, vous pouvez choisir de faire une mise à jour de world au lieu de seulement system, pour être certain que tous les paquets soient mis à jour.
Suppression des anciennes versions Désinstallez enfin les anciennes versions de GCC sans risque en remplaçant VOTRE-NOUVELLE-VERSION-DE-GCC par la version que vous venez d'installer :
Il est important de désactiver distcc durant la mise à jour. Mélanger les versions de compilateurs sur vos nœuds provoquera des problèmes au niveau de la compilation. Vous pouvez garder ccache activé étant donné que les objets en cache seront invalidés automatiquement. Utilisez toujours la même version de GCC pour votre noyau et les modules additionnels du noyau. Une fois votre « world » recompilé avec votre nouveau GCC, les modules externes (comme app-emulation/qemu-softmmu) échoueront lors de leur chargement. Il suffit de recompiler votre noyau pour résoudre ce problème. Si vous mettez à jour une machine SPARC, n'oubliez pas de relancer silo -f après avoir recompilé world afin d'éviter d'éventuels problèmes. Si vous recevez un message d'erreur du type libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool archive, il faut alors exécuter /usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.3.6 (remplacez « 3.3.6 » par le numéro de version mentionné dans le message, $CHOST par votre véritable CHOST et gcc-version par votre version de GCC). Si vous avez l'erreur error: /usr/bin/gcc-config: line 632: /etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory, essayez alors de supprimer /etc/env.d/gcc/config-i686-pc-linux-gnu et lancez de nouveau gcc-config, suivi de source /etc/profile. Ne faites pas cela si vous utilisez la compilation croisée. Si un paquet échoue durant emerge -e system ou emerge -e world, vous pouvez relancer l'opération avec la commande emerge --resume. Si un paquet continue d'échouer, passez au paquet suivant avec la commande emerge --resume --skipfirst. Ne lancez aucun autre emerge entre-temps car cela effacerait les informations qui permettent la reprise. Si vous obtenez un message d'erreur du type spec failure: unrecognized spec option alors que vous mettez votre compilateur à jour, tentez de repasser à la version de GCC que vous utilisiez auparavant. Supprimez la variable GCC_SPECS et relancez la mise à jour de GCC :
Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5. |
|