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 el sistema. Así pues, ¿Por qué hay una guía para ello?

Hay ciertas situaciones en las que el cambio de CHOST es inevitable, por ejemplo, si se quiere actualizar a glibc 2.4 que únicamente admite nptl y se encuetra que su CHOST es i386, lo que hace imposible el uso de nptl. En este caso no hay muchas opciones y cambiar CHOST es una de ellas.

Incluso siguiendo estas instrucciones pueden surgir problemas así que, por favor, asegúrese de leer y ejecutarlas con mucho cuidado. En este ejemplo se cambiará CHOST desde i386 a i686. Si se quiere hacer otro cambio distinto, por favor, modifique las órdenes apropiadamente.

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

Verifying things work
Now it is time to make sure that your  and   settings are sane and you do not have any leftovers in.

The output of  and   should look like this (may differ according to your gcc version and chost, gcc 4.1.1 and i686 here):

A continuación compruebe si hay referencias al antiguo CHOST en :

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

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

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

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

and are fine, but  is another leftover that needs removal.

Now run the following commands to update your environment:

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

If you still find something, you must have missed some file, try to track it down before going on.

Terminar con el cambio
Now it is necessary to re-emerge  and run. Make sure to use the correct gcc version (your current one, 4.1.1 here) and pass your old architecture (i386 here) as argument. Replace $CHOST with your new CHOST, and  with your gcc version. This example assumes a CHOST of i686.

Quizás quiera volver a reconstruir todos los paquetes:

Now, in theory it should not be necessary to do so, but it can not be 100% guaranteed that this is actually the case. If you do not recompile the world target, I have been told at least some packages need recompiling, so you should do:

All packages using perl install to the CHOST directory and hence need remerging. In case you haven't installed, you will need to install  first.

If you encounter other packages that need recompiling, please let the author of this document know.

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

This happens because during the upgrade, the CHOST doesn't exactly match CTARGET and the compiler assumes cross-compiling. As a consequence, LDPATH isn't inserted into, resulting in this error.

Please see our 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 your old chost and gcc version) to, running   and then. However, as you can see, you really should avoid running into this problem - don't change CHOST and your gcc version at the same time.

Comentarios
Eso sería todo, los comentarios (tanto si funcionó, falló o se encontraron otros problemas) son bienvenidos, por favor envíe un correo electrónico a o publique en este hilo del foro. La mayor parte de este documento lo ha escrito vapier, ¡Gracias por tu ayuda!