Changing the CHOST variable/es

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

Introducción
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.

Construir los paquetes
To start out with the CHOST variable change, edit the file and change the CHOST value to suit the requirements. Then, rebuild the following packages in this order:

Comprobar que la cosa funciona
Now it is time to make sure that the and  settings are sane and that there are no leftovers in.

The output of and  should look like the following:

Next, check to see if there are references to the old CHOST variable in :

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

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

The same also applies to - if there's an extra one, see which is the outdated one and delete it. Next, check the contents of :

Este parece correcto, los dos ficheros deberían estar ahí. Es el momento de moverlos al directorio.

y son correctos, sin embargo  un sobrante que se debe eliminar.

Ahora lance las siguientes órdenes para actualizar el entorno:

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

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 and run  which can be found in. 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  with the new CHOST value, and   with the gcc version. This example assumes a CHOST value applicable to i686.

Ahora será posible reconstruir todos los paquetes:

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

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

Ahora se deben reconstruir todos los paquetes que tiene fichero instalados en la localización :

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

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 (change accordingly to the old CHOST and gcc version) to, running  and then. However, as can be seen, this situation needs to be avoided - don't change CHOST and gcc at the same time.

Comentarios
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!