Cambiar 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 100% complete.

Other languages:
English • ‎español • ‎français • ‎日本語 • ‎한국어 • ‎русский

This document explains how to change the CHOST variable of an existing system.


Changing the CHOST is a big issue that can seriously screw up a system - so why is there a guide for that if it can cause that much havoc?

There are certain situations where changing the CHOST variable is inevitable, e.g. when upgrading to glibc 2.4 which only supports nptl and the user finds out that the current CHOST is i386, which makes it impossible to use nptl. In this case, there are not a lot of options, and changing CHOST is one of them.

Even after following these instructions, problems may arise, so please make sure to read and execute them very carefully. In this example the CHOST variable will be changed from i386 to i686. Please change the commands according to the personal situation.

Cambiar la variable CHOST

Construir los paquetes

To start out with the CHOST variable change, edit the /etc/portage/make.conf file and change the CHOST value to suit the requirements. Then, rebuild the following packages in this order:

root #emerge --ask binutils gcc glibc
Please be aware that major gcc upgrades executed at the same time as changing the CHOST variable (e.g. starting with gcc 3.3, CHOST i386 and switching to gcc 4.1, CHOST i686) can lead to severe side effects. 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. As a consequence, please do one thing at a time, e.g. upgrade gcc first according to the gcc upgrade guide and change the CHOST afterwards. 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.
It may be necessary to run binutils-config before compiling gcc.

Comprobar que la cosa funciona

Now it is time to make sure that the gcc-config and binutils-config settings are sane and that there are no leftovers in /etc/env.d/.

The output of gcc-config and binutils-config should look like the following:

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
root #binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c

Next, check to see if there are references to the old CHOST variable in /etc/env.d/:

root #cd /etc/env.d/
root #grep 386 *
This may not happen in every case, but in this case 05gcc-i386-pc-linux-gnu contains references to the old CHOST value. Things may look differently on each system depending on which CHOST value the system is changing to/from. In some cases, no references are left at all. The name may also be 05gcc-new_CHOST-pc-linux-gnu.

Before deleting the file, let's check for files with the updated CHOST value:

root #grep 686 *

Este tiene buena pinta, ya que siempre debe haber un solo archivo para gcc en /etc/env.d/ (05gcc en este ejemplo), por lo que se debe eliminar el que tiene las referencias incorrectas:

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

The same also applies to binutils - if there's an extra one, see which is the outdated one and delete it. Next, check the contents of /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
root #cat i686-pc-linux-gnu-2.16.1

Este parece correcto, los dos ficheros deberían estar ahí. Es el momento de moverlos al directorio 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
root #cat config-i386-pc-linux-gnu
root #cat i686-pc-linux-gnu-4.1.1

config y i686-pc-linux-gnu-4.1.1 son correctos, sin embargo config-i386-pc-linux-gnu un sobrante que se debe eliminar.

De nuevo, el nombre del archivo que contiene referencias a una versión anticuada de gcc puede tener un nombre diferente, por ejemplo, config-i686-pc-linux-gnu incluso si el sistema se está cambiando a (en este caso) i686. Es importante identificar el archivo leyendo su contenido, no sólo su nombre.
root #rm config-i386-pc-linux-gnu

Ahora lance las siguientes órdenes para actualizar el entorno:

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

A continuación compruebe que todo está en su sitio:

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

Si todavía aparece algún fichero, inténte echarle un vistazo antes de continuar.

Terminar con el cambio

Now it is necessary to re-emerge sys-devel/libtool and run which can be found in /usr/share/gcc-data/$CHOST/<gcc-version>/. Make sure to use the correct gcc version (the current one, 4.1.1 here) and pass the old architecture (i386 here) as argument. Replace $CHOST with the new CHOST value, and <gcc-version> with the gcc version. This example assumes a CHOST value applicable to i686.

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

Ahora será posible reconstruir todos los paquetes:

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.

Se necesita reconstruir el siguiente conjunto de paquetes

root #emerge --ask python

All packages using perl install to the CHOST directory and hence need rebuilding. In case qfile is not available on the system yet, install app-portage/portage-utils first.

root #emerge --ask portage-utils

Ahora se deben reconstruir todos los paquetes que tiene fichero instalados en la localización /usr/lib/perl*:

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

When encountering other packages that need recompiling, please let us know through the discussion page of this guide.

Problemas comunes

When upgrading from gcc 3.3 to 4.1 at the same time as changing the CHOST variable (please don't do that anyway), a couple of users reported broken packages that need recompiling, such as sys-apps/groff and mail-mta/courier:

CÓDIGO Mensaje de error
error while loading shared libraries: cannot open shared object file: No such file or directory

This happens because during the upgrade, the CHOST variable doesn't exactly match the CTARGET variable value, making the compiler assume that the system is using cross-compiling. As a consequence, LDPATH isn't inserted into, resulting in this error.

Por favor, consulte la guía de Actualización de GCC para saber lo que se necesita reconstruir después de una actualización de GCC.

In some rare cases, this can break old versions of python, too. This may be fixed by adding /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (change accordingly to the old CHOST and gcc version) to /etc/, running ldconfig and then emerge libstdc++-v3. However, as can be seen, this situation needs to be avoided - don't change CHOST and gcc at the same time.


That should be all, feedback (both if it worked, failed or other problems were encountered) is welcome, please use the discussion page or post to this forum thread. Much in this guide comes from vapier, thanks for your help!

This article is based on a document formerly found on our main website
The following people contributed to the original document: Wernfried Haas, Mike Frysinger, Chris White
They are listed here as the 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 the history page.