Changer la variable CHOST

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Changing the CHOST variable and the translation is 20% complete.
Outdated translations are marked like this.

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

Changer la variable CHOST est un problème délicat qui peut sérieusement mettre en péril un 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.

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"

Note that profiles provide a default setting for CHOST; depending on the situation, it may be necessary to override it in /etc/portage/make.conf or remove an override in /etc/portage/make.conf. In any case, the important point is that the effective value changes.

Please note that if planning to use another value of CHOST than the profile default, the CHOST_${ABI} variable may need updating as well. It is possible to query the value of this variable of the currently set profile with the portageq tool:

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

If this value is equal to CHOST, it's good. Otherwise, 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 multiple slots are installed, either uninstall extraneous slots or rebuild all of them. If that is not possible, 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.
Important
If the CHOST switch takes place together with other changes, e.g. in the course of a profile upgrade, please read the documentation there as well to make sure the different steps do not interfere.

Rebuild the following packages in this order:

root #emerge --ask --oneshot sys-devel/binutils
Remarque
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

For glibc based systems:

root #emerge --ask --oneshot sys-libs/glibc

For musl based systems:

root #emerge --ask --oneshot sys-libs/musl

Vérifier que tout fonctionne

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

La sortie de gcc-config et de binutils-config devrait ressembler à ce qui suit :

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

Here, binutils is fine - there is one file, and it only contains references to the new CHOST. For gcc, there is a file for both the new and the old CHOST value, so delete the old stale one:

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 le contenu de /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 être présents. Il est temps de se déplacer dans le répertoire gcc/.

root #rm config-mips64-unknown-linux-gnu

Time to move on to the gcc/ directory.

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é.

Remarque
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 l'environnement à jour.

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

Ensuite, vérifiez que tout est correctement réglé :

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 --oneshot libtool

Il est maintenant possible de recompiler tous les paquets :

root #emerge --ask --emptytree @world

In theory, it should not be necessary to do so, but it cannot be 100% guaranteed that this is actually the case. Alternatively, it is possible to 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 paths that do not apply to the current system may need removing 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

Not so many anymore. Usually this just works, as long as no really exotic change is done. Make sure to not combine the CHOST change with other steps though. Some of the notes below are really old...

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 sys-apps/groff et mail-mta/courier :

CODE Message 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 !


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.