Changer la variable CHOST

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Changing the CHOST variable and the translation is 38% complete.

Outdated translations are marked like this.
Other languages:
English • ‎español • ‎français • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

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

Updating make.conf

To start out with the CHOST variable change, edit the /etc/portage/make.conf file and add/change the CHOST value to suit the requirements.

FILE /etc/portage/make.conf
CHOST="i686-pc-linux-gnu"

Please note that if you are planning to use another value of CHOST than the profile default, you may need to update the CHOST_${ABI} variable as well. You can query the current value of these variable via portageq tool:

user $portageq envvar ABI
x86
user $portageq envvar CHOST_x86
i686-pc-linux-gnu

If this value is equal to your CHOST, you're good. Otherwise, you should override it as well, e.g.:

FILE /etc/portage/make.conf
CHOST_x86="i686-pc-linux-gnu"

Compiler les paquets

Important
It is generally a good idea to rebuild the packages to the same versions as before the CHOST switch, i.e. avoiding combining upgrades with it. If you have multiple slots installed, either uninstall extraneous slots or rebuild all of them. If you can't do that, please upgrade the packages first (with old CHOST). While it may not be impossible to do so, it is hard to predict which potential problems may arise and almost impossible to document them in this guide.
Tip
On a system with CHOST set to an i386 value, mask glibc 2.4 (or newer) during the gcc upgrade as it cannot be used with i386. Unmask it once the change has been performed completely.

Rebuild the following packages in this order:

root #emerge --ask --oneshot sys-devel/binutils
Note
It may be necessary to run binutils-config before compiling gcc.
root #emerge --ask --oneshot sys-devel/gcc
root #emerge --ask --oneshot sys-libs/glibc

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) :

Note
The output may, or even will differ according to the gcc version and CHOST settings. The example below uses gcc 4.1.1 on 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

In theory, it should not be necessary to do so, but it cannot be 100% guaranteed that this is actually the case. Alternatively, you can manually rebuild all the known problematic packages:

  • multilib packages using CHOST prefixing or header wrapping,
  • Perl, Python and other tools that store configured compiler path.
root #emerge --ask --oneshot /usr/bin/i386-pc-linux-gnu-* /usr/include/i386-pc-linux-gnu /usr/lib/llvm/*/bin/i386-pc-linux-gnu-* dev-lang/perl dev-lang/python

Note that you may need to remove paths that do not apply to your system from the above invocation.

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

'"`UNIQ--pre-0000000F-QINU`"'

This is a deprecated template and will be removed soon!!! Help us update this template!

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 !


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Wernfried Haas, Mike Frysinger (vapier), Chris White
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.