Changing the CHOST variable/es

Este documento Article description::describe como cambiar la variable [[CHOST en un sistema ya existente.]]

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 CHOST es inevitable, por ejemplo, cuando se actualiza a glibc 2.4 que únicamente ofrece soporte para NTPL y el usuario comprueba que el valor actual de 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 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 CHOST desde i386 a i686. Por favor, modifique las órdenes apropiadamente dependiendo de la situación específica.

Actualizar make.conf
Para comenzar el cambio de la variable CHOST, edite el fichero y añada o cambie el valor de la variable CHOST para ajustarse a los requisitos.

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

Por favor, observe que, si está planeando usar otro valor para CHOST distinto al que ofrece el perfil por defecto, puede que sea necesario actualizar también la variable CHOST_${ABI}. Puede consultar el valor actual de estas variables a través de la herramienta portageq:

Si este valor es el mismo que su CHOST, todo está en sitio, de lo contrario debería sobrescribirlo, por ejemplo.

Construir los paquetes
Reconstruya los siguientes paquetes en este orden:

Comprobar que la cosa funciona
Ahora es el momento de asegurarse de que los ajustes y  son correctos y que no nada que sobre en.

La salida de y  debería tener el siguiente aspecto:

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

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:

Lo mismo se aplica a, si hay uno extra, compruebe el que está desactualizado y elimínelo. A continuación compruebe el contenido de.

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

Time to move on to the directory.

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:

Terminar con el cambio
Ahora es necesario hacer de nuevo emerge de y lanzar  que se puede encontrar en. Asegúrese de utilizar la versión adecuada de gcc (La actual aquí es la 4.1.1) y pase la arquitectura anterior (aquí es la i386) como argumento. Reemplace  por el nuevo valor CHOST, y   por la versión de gcc. En este ejemplo se asume un valor para CHOST aplicable a i686.

Ahora será posible reconstruir todos los paquetes:

En teoría, no debería ser necesario hacerlo, sin embargo no se puede garantizar al 100% que ese sea el caso. De forma alternativa, se pueden reconstruir manualmente todos los paquetes problemáticos:
 * Paquetes multilib que utilicen el prefijo CHOST en la envoltorio de cabecera,
 * Perl, Python y otras herramientas que almacenan rutas configuradas del compilador.


 * multilib packages using CHOST prefixing or header wrapping,
 * Perl, Python and other tools that store configured compiler path.

Observe que puede necesitar eliminar rutas que no aplican a su sistema con la invocación citada arriba.

Si encuentra otros paquetes que se necesita reconstruir, por favor, hagánoslo saber a través de la página de discusión de esta guía.

Problemas comunes
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...

Cuando se actualiza desde gcc 3.3 a 4.1 al mismo tiempo que se cambia la variable CHOST (por favor, no lo haga de cualquier modo), un par de usuarios informaron de paquetes rotos que necestan reconstrucción, como por ejemplo y :

Esto ocurre porque durante la actualización, la variable CHOST no coincide exactamente con el valor de la variable CTARGET, causando que el compilador asuma que el sistema está utilizando compilación cruzada. Como consecuencia de todo esto, LDPATH no se inserta en y se produce este 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.

En algunos casos poco comunes, esto también puede romper anteriores versiones de python. Esto se puede corregir añadiendo (cambie esto de forma apropiada dependiendo de valor anterior de la variable  CHOST y de la versión de gcc) a, lanzando  y luego haciendo. Sin embargo, como se puede comprobar, se debe evitar esta situación. No cambie CHOST y gcc al mismo tiempo.

Comentarios
Eso sería todo, los comentarios (tanto si funcionó, falló o se encontraron otros problemas) son bienvenidos, por favor, utilice la página de discusión o publique un hilo de discusión en este hilo del foro. La mayor parte de esta guía la ha escrito vapier, ¡Gracias por tu ayuda!