Changer la variable CHOST

From Gentoo Wiki
Revision as of 06:23, 1 September 2013 by Jaaf (Talk | contribs)

Jump to: navigation, search
Other languages:English 100% • ‎français 85% • ‎한국어 85% • ‎русский 100%

Ce document explique comment changer la variable CHOST d'un système existant.

Introduction

Changer la variable CHOST est un problème délicat qui peut sérieusement mettre en péril votre système. Alors, pourquoi faire un guide sur ce sujet ?

Il existe des situations où changer CHOST est inévitable, par exemple quand vous voulez mettre glibc à jour vers la version 2.4 qui ne supporte que nptl et que vous vous rendez compte que votre CHOST est i386, ce qui rend l'utilisation de nptl impossible. Dans un tel cas, vous n'avez guère d'options et changer CHOST en est une.

Même si vous suivez ces instructions, des problèmes peuvent surgir, c'est pourquoi vous devez les lire et les exécuter très prudemment. Dans cet exemple la variable CHOST sera changée de i386 en i686, si votre changement est différent, bien-sûr, adaptez les commandes en conséquence.

Changer la variable CHOST

Compiler les paquets

Pour vous lancer dans le changement de la variable CHOST, éditez le fichier /etc/portage/make.conf et changer la valeur CHOST selon votre besoin. Ensuite, recompilez les paquets suivants dans l'ordre indiqué :

root # emerge --ask binutils gcc glibc
Important
Surtout soyez conscient que des mises à jour majeures de gcc concomitantes à un changement de la variable CHOST (par exemple commencer avec gcc 3.3, CHOST i386 et commuter vers gcc 4.1, CHOST i686) peut induire de graves effets de bord. Bien qu'il ne soit pas impossible de le faire, il est difficile de prédire quels problèmes potentiels peuvent surgir et de les documenter dans ce guide. En conséquence, s'il vous plaît, faites une chose à la fois, par exemple, mettez d'abord gcc à jour en suivant notre guide de mise à jour de gcc et changez la variable CHOST après. Si vous êtes sur un système avec CHOST=i386, vous devrez masquer glibc 2.4 (ou plus récent) pendant la mise à jour de gcc, car il ne peut être utilisé avec i386, et démasquez le une fois que vous avez terminé.

Vérifier que tout fonctionne

Maintenant, il est temps de vous assurer que les réglages de gcc-config et de binutils-config sont sains et que vous n'avez aucun résidu dans /etc/env.d/ .

La sortie de gcc-config et de binutils-config devrait ressembler à ce qui suit (peut différer selon votre version de gcc et de chost, dans ce cas, il s'agit de gcc 4.1.1 et de i686) :

root # gcc-config -l
 [1] i686-pc-linux-gnu-4.1.1 *
root # gcc-config -c
i686-pc-linux-gnu-4.1.1
root # binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c
i686-pc-linux-gnu-2.16.1

Ensuite, vérifiez s'il y a des références à l'ancienne variable CHOST dans /etc/env.d/ :

root # cd /etc/env.d/
root #
grep 386 *
05gcc-i386-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"
05gcc-i386-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"
Note
Ceci ne va pas forcément vous arriver, mais dans ce cas ,05gcc-i386-pc-linux-gnu contient des réferences à l'ancienne variable CHOST. Les choses peuvent apparaître différentes sur votre système selon le changement que vous êtes en train de faire à CHOST, ou très bien se passer. Le nom peut aussi être 05gcc-votre_nouvelle_CHOST-pc-linux-gnu.

Avant d'effacer le fichier, vérifions que des fichiers avec la nouvelle variable CHOST existent :

root # grep 686 *
05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man
05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info
05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib
05gcc:PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
05gcc:INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
05gcc:LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"

Cela paraît bon car il doit toujours n'y avoir qu'un seul fichier pour gcc dans /etc/env.d/ (05gcc dans notre exemple). Supprimons donc celui avec les mauvaises références :

root # rm 05gcc-i386-pc-linux-gnu

Cela est aussi vrai pour binutils - s'il existe un fichier supplémentaire, cherchez celui qui est obsolète et supprimez le. Ensuite vérifiez votre /etc/env.d/binutils/.

root # cd /etc/env.d/binutils/
root #
ls -la
total 8
-rw-r--r-- 1 root root  15 Sep  3 13:48 config-i686-pc-linux-gnu
-rw-r--r-- 1 root root 126 Sep  3 13:48 i686-pc-linux-gnu-2.16.1
root # cat config-i686-pc-linux-gnu
CURRENT=2.16.1
root # cat i686-pc-linux-gnu-2.16.1
TARGET="i686-pc-linux-gnu"
VER="2.16.1"
LIBPATH="/usr/lib/binutils/i686-pc-linux-gnu/2.16.1"
FAKE_TARGETS="i686-pc-linux-gnu"

Celui-ci paraît bon, ces deux fichiers devraient réellement être présents. Il est temps de se déplacer dans le répertoire gcc.

root # cd /etc/env.d/gcc
# ls -la
total 12
-rw-r--r-- 1 root root  32 Sep  3 16:43 config
-rw-r--r-- 1 root root  32 Aug  3 14:25 config-i386-pc-linux-gnu
-rw-r--r-- 1 root root 292 Sep  3 16:43 i686-pc-linux-gnu-4.1.1
root # cat config
CURRENT=i686-pc-linux-gnu-4.1.1
root # cat config-i386-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-4.1.1
root # cat i686-pc-linux-gnu-4.1.1
PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"
GCCBITS="32"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
STDCXX_INCDIR="g++-v4"

config et i686-pc-linux-gnu-4.1.1 sont corrects, mais config-i386-pc-linux-gnu est un autre résidu qui doit être supprimé.

Note
Répétons-le, le nom du fichier contenant des références à une version obsolète de gcc peut avoir un nom différent, par exemple, config-i686-pc-linux-gnu, si vous changez vers i686. Il est important que vous identifiiez le fichier par son contenu, pas seulement par son nom.
root # rm config-i386-pc-linux-gnu

Maintenant exécutez les commandes suivantes pour mettre votre environnement à jour.

root # env-update && source /etc/profile

Puis vérifiez que tout est correctement réglé :

root # grep -r 386 /etc/env.d/

Si vous trouvez encore quelque chose, vous avez probablement manqué quelques fichiers, essayez de les repérer avant d'aller plus loin.

Terminer le changement

Maintenant, il faut réinstaller libtool et run /usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh . Assurez-vous d'utiliser la version de gcc correcte (votre version courante est 4.1.1 et l'ancienne architecture, i386 dans ce cas). Remplacez $CHOST avec votre nouvelle CHOST, et <gcc-version> par votre version de gcc . Cet exemple suppose que la variable CHOST est i686.

root # emerge --ask libtool
root # /usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/fix_libtool_files.sh 4.1.1 --oldarch i386-pc-linux-gnu

Vous pouvez recompiler tous vos paquets :

root # emerge -e world

Maintenant, bien qu'en théorie cela ne devrait pas être nécessaire, mais nous ne pouvons le garantir à 100%, recompilez votre cible world. J'ai entendu dire que quelques paquets au moins, nécessitaient cette re-compilation ; aussi faites ceci :

root # emerge --ask python

Tous les paquets utilisant perl installent le répertoire CHOST et par conséquent nécessitent une réinstallation. Dans le cas où vous n'auriez pas installé qfile , vous devez installer app-portage/portage-utils d'abord.

root # emerge --ask portage-utils
root # emerge -av1 `qfile /usr/lib/perl* -Cq | sort -u`

Si vous rencontrez d'autres paquets qui nécessitent la recompilation, faites le savoir à l'auteur de ce document.

Problèmes courants

Lorsque vous mettez à jour gcc de la version 3.3 vers la version 4.1 en même temps que vous changez la variable CHOST (s.v.p. ne faites ça en aucun cas), quelques utilisateurs ont fait état de paquets cassés qui nécessitent une recompilation, comme par exemple groff et courier :

CodeMessage d'erreur

error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Ceci se produit car pendant la mise à jour, la variable CHOST ne correspond pas exactement à CTARGET et que le compilateur suppose qu'il s'agit d'une compilation croisée. En conséquence, LDPATH n'est pas inséré dans ld.so.conf, ce qui conduit à cette erreur.

Reportez-vous à notre guide de mise à jour de gcc pour savoir ce qu'il faut recompiler après une mise à jour de gcc.

Dans quelques rares cas, ceci peut casser d'anciennes versions de python également. On peut régler ce problème en ajoutant /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (changez selon votre CHOST et votre version de gcc ) à /etc/ld.so.conf

Retour d'expérience

Ce sera tout. Un retour d'expérience (à la fois si les choses se sont bien passées, ou si des problèmes ont été rencontrés) est bienvenu. Envoyez un courriel à amne@gentoo.org ou postez sur ce fil de discussion sur les forums. La majeure partie de ce guide provient de vapier. Merci pour votre aide !

Remerciements

Nous tenons à remercier les auteurs et éditeurs suivants pour leur contribution à ce guide :


  • Wernfried Haas
  • Mike Frysinger
  • Chris White