Changing the CHOST variable/es

Este documento describe como cambiar la variable CHOST en un sistema ya existente.

Introducción
Cambiar el CHOST es una cuestión importante ya que puede desestabilizar seriamente un sistema. Así pues, ¿Por qué hay una guía para algo que puede crear tantos quebraderos de cabeza?

Hay ciertas situaciones en las que el cambio de la variable  es inevitable, por ejemplo, cuando se actualiza a glibc 2.4 y el usuario comprueba que el   actual es i386, lo que hace imposible el uso de nptl. En este caso no hay muchas opciones y cambiar  es una de ellas.

Incluso después de seguir estas instrucciones pueden surgir problemas así que, por favor, asegúrese de leer y ejecutarlas con mucho cuidado. En este ejemplo se cambiará la variable  desde i386 a i686. Por favor, modifique las órdenes apropiadamente dependiendo de la situación del usuario.

Construir los paquetes
Para comenzar con el cambio de la variable, edite el archivo   y cambie el valor de   para adaptarlo a los requisitos. A continuación reconstruya los siguientes paquetes en este orden:

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.

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

A continuación compruebe si hay referencias a la variable  anterior en :

Antes de eliminar el archivo, compruebe que haya ficheros con el valor de  actualizado:

This one looks good as there should always be only one file for  in  ( in this example), so delete the one with the wrong references:

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 :

That one looks good, those two files should be there. Time to move on to the directory.

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

Now run the following commands to update the environment:

Next, verify everything is fixed:

If there are still files found, try to track it down before going on.

Terminar con el cambio
Now it is necessary to re-emerge libtool and run fix_libtool_files.sh 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   value, and   with the gcc version. This example assumes a  value applicable to i686.

It is now possible to rebuild all the packages:

In theory, it should not be necessary to do so, but it can not be 100% guaranteed that this is actually the case.

The following set of packages really need to be rebuilt:

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

Now rebuild all packages that have files installed in any location:

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  variable (please don't do that anyway), a couple of users reported broken packages that need recompiling, such as groff</tt> and courier</tt>:

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

Please see the GCC upgrade guide for what needs to be rebuilt after a GCC upgrade.

In some rare cases, this can break old versions of python, too. This may be fixed by adding (change accordingly to the old   and gcc version) to, running ldconfig and then emerge libstdc++-v3. However, as can be seen, this situation needs to be avoided - don't change  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!