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 • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

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

Cambiar la variable CHOST

Actualizar make.conf

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

ARCHIVO /etc/portage/make.conf
CHOST="i686-pc-linux-gnu"

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:

user $portageq envvar ABI
x86
user $portageq envvar CHOST_x86
i686-pc-linux-gnu

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

ARCHIVO /etc/portage/make.conf
CHOST_x86="i686-pc-linux-gnu"

Construir los paquetes

Importante
Por lo general es una buena idea reconstruir los paquetes a las misma versiones que tenian antes del cambio de variable CHOST, esto es, se debe tratar de evitar actualizaciones cuando se haga el cambio. Si tiene distintos slots instalados, bien, desinstale los slot extraño o reconstrúyalos todos. Si no puede hacer esto, por favor, actualice primero el paquete (con el valor antiguo de CHOST). Aunque esto no es imposible de realizar, es difícil predecir que problemas potenciales pueden surgir y por tanto es imposible documentarlos en esta guía.
Tip
En un sistema en el que se haya definido CHOST con el valor i386, enmascare glibc 2.4 (o más actual) durante la actualización de gcc ya que no se puede utilizar con i386. Desenmascárelo una vez se haya realizado correctamente el cambio.

Reconstruya los siguientes paquetes en este orden:

root #emerge --ask --oneshot sys-devel/binutils
Nota
Puede que se necesite lanzar binutils-config antes de compilar gcc.
root #emerge --ask --oneshot sys-devel/gcc
root #emerge --ask --oneshot sys-libs/glibc

Comprobar que la cosa funciona

Ahora es el momento de asegurarse de que los ajustes gcc-config y binutils-config son correctos y que no nada que sobre en /etc/env.d/.

La salida de gcc-config y binutils-config debería tener el siguiente aspecto:

Nota
Probablemente la salida será distinta dependiendo de la versión de gcc y de los ajustes CHOST. En el ejemplo de abajo se utiliza gcc 4.1.1 en un arquitectura i686.
root #gcc-config -l
 [1] i686-pc-linux-gnu-4.1.1 *
root #gcc-config -c
i686-pc-linux-gnu-4.1.1
root #binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c
i686-pc-linux-gnu-2.16.1

A continuación compruebe si hay referencias a la variable CHOST anterior en /etc/env.d/:

root #cd /etc/env.d/
root #grep 386 *
05gcc-i386-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"
05gcc-i386-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"
Nota
Puede que esto ocurra en todos los casos, pero en este, 05gcc-i386-pc-linux-gnu contiene referencias al valor anterior de CHOST. Las cosas pueden ser de otra forma en otros sistemas dependiendo de el valor de CHOST hacia o desde el que se está cambiando. En algunos casos no se deja ninguna referencia. El nombre también puede ser 05gcc-nuevo_CHOST-pc-linux-gnu.

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

root #grep 686 *
05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man
05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info
05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib
05gcc:PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
05gcc:INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
05gcc:LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"

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

Lo mismo se aplica a binutils, si hay uno extra, compruebe el que está desactualizado y elimínelo. A continuación compruebe el contenido de /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
CURRENT=2.16.1
root #cat i686-pc-linux-gnu-2.16.1
TARGET="i686-pc-linux-gnu"
VER="2.16.1"
LIBPATH="/usr/lib/binutils/i686-pc-linux-gnu/2.16.1"
FAKE_TARGETS="i686-pc-linux-gnu"

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
CURRENT=i686-pc-linux-gnu-4.1.1
root #cat config-i386-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-4.1.1
root #cat i686-pc-linux-gnu-4.1.1
PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"
GCCBITS="32"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
STDCXX_INCDIR="g++-v4"

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

Nota
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

Ahora es necesario hacer de nuevo emerge de sys-devel/libtool y lanzar fix_libtool_files.sh que se puede encontrar en /usr/share/gcc-data/$CHOST/<versión-de-gcc>/. 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 $CHOST por el nuevo valor CHOST, y <versión-de-gcc> por la versión de gcc. En este ejemplo se asume un valor para CHOST aplicable a i686.

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

Ahora será posible reconstruir todos los paquetes:

root #emerge --ask --emptytree @world

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.
root #emerge --ask --oneshot /usr/bin/i386-pc-linux-gnu-* /usr/include/i386-pc-linux-gnu /usr/lib/llvm/*/bin/i386-pc-linux-gnu-* dev-lang/perl dev-lang/python

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

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 sys-apps/groff y mail-mta/courier:

CÓDIGO Mensaje de error
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

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 ld.so.conf 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 /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (cambie esto de forma apropiada dependiendo de valor anterior de la variable CHOST y de la versión de gcc) a /etc/ld.so.conf, lanzando ldconfig y luego haciendo emerge libstdc++-v3. 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!


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Wernfried Haas, Mike Frysinger (vapier), Chris White
They are listed here because 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 each article's associated history page.