Cambiando la variable CHOST
1.
Introducción
Cambiar el CHOST es un asunto importante que puede seriamente
desestabilizar el sistema - así que ¿porqué existe esta guía?
Existen ciertas situaciones donde cambiar el CHOST es inevitable, por
ejemplo, si desea actualizar al glibc 2.4 que solo soporta nptl y
averigua que el CHOST es un i386, lo cual imposibilita el uso de
nptl. En este caso no existe una variedad de opciones y cambiar el
CHOST es una de ellas.
Aún siguiendo estas instrucciones puede surgir problemas, así que por
favor asegúrese de leer y ejecutarlas con sumo cuidado. En este
ejemplo cambiaremos el CHOST de i386 a i686 y si su situación es
diferente, por favor haga los cambios de rigor en los comandos.
2.
Cambiando la variable CHOST
Construyendo los paquetes
Para comenzar con el cambio de CHOST, modifique el archivo
/etc/portage/make.conf y cambie el valor de
CHOST según sus necesidades. Luego, reconstruya estos
paquetes en el siguiente orden:
Listado de Código 2.1: Reconstruyendo las herramientas del sistema importantes |
# emerge -av1 binutils gcc glibc
|
Importante:
Por favor tome en cuenta la advertencia que actualizar el gcc al mismo
tiempo que hacer el cambio de CHOST (como por ejemplo comenzar con un
gcc 3.3 y un CHOST i386 y cambiar a un gcc 4.1 y un CHOST i686) puede
conllevar unos severos efectos colaterales. Aunque tal vez no sea
imposible, es difícil predecir cuáles problemas potenciales pueden
surgir y documentarlos en esta guía. Como consecuencia, le rogamos
haga una cosa a la vez, por ejemplo actualizar el gcc primero de
acuerdo a nuestra guía de
actualización del gcc y luego cambiar el CHOST. Si está en un
sistema con el CHOST=i386, necesita enmascarar el glibc 2.4 (o más
reciente) durante la actualización del gcc ya que no puede ser usado
con i386 y luego desenmascararlo al terminar.
|
Verificando el funcionamiento
Ahora es el momento de asegurarse que la configuración de
gcc-config y binutils-config están sanos y que no tiene
el /etc/env.d/ embasurado.
La salida de gcc-config y de binutils-config deberían
parecerse a (podría ser distinto según su versión de gcc y CHOST,
siendo el gcc 4.1.1 y CHOST i686 en este caso):
Listado de Código 2.2: Verificando una configuración sana |
# gcc-config -l
[1] i686-pc-linux-gnu-4.1.1 *
# gcc-config -c
i686-pc-linux-gnu-4.1.1
# binutils-config -l
[1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c
i686-pc-linux-gnu-2.16.1
|
Luego revisemos si tenemos alguna referencia antigua al CHOST viejo en
/etc/env.d/:
Listado de Código 2.3: Revisando la existencia de referencias al CHOST viejo |
# cd /etc/env.d/
# 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:
Esto tal vez no le ocurra, pero en este caso 05gcc-i386-pc-linux-gnu
contiene referencias al CHOST anterior. Las cosas pueden lucir
distintas en su sistema, dependiendo de cuál CHOST se está cambiando
de/a, o tal vez hasta esté perfecto. El nombre puede ser también
05gcc-nuevo_CHOST-pc-linux-gnu.
|
Antes de borrar este archivo, revisemos si hay archivos con el CHOST
actualizado:
Listado de Código 2.4: Revisando la presencia de archivos con el CHOST actualizado |
# 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"
|
Esto se ve bien, ya que siempre debe haber un solo archivo para el
gcc en /etc/env.d/ (en este ejemplo, el 05gcc),
así que borremos el que tiene las referencias equivocadas:
Listado de Código 2.5: Borrando los archivos con las referencias incorrectas |
# rm 05gcc-i386-pc-linux-gnu
|
Lo mismo aplica a binutils - si hay uno extra, verifique que
sea antiguo y bórrelo. a continuación revise su directorio
/etc/env.d/binutils/:
Listado de Código 2.6: Chequeando el binutils correcto |
# cd /etc/env.d/binutils/
# 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
# cat config-i686-pc-linux-gnu
CURRENT=2.16.1
# 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"
|
Esto está bien, ambos archivos deben estar donde están. Hora de
continuar al directorio gcc.
Listado de Código 2.7: Chequeando el gcc correcto |
# 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
# cat config
CURRENT=i686-pc-linux-gnu-4.1.1
# cat config-i386-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-4.1.1
# 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 estan bien,
pero config-i386-pc-linux-gnu es otro remanente que hay
que borrar.
Nota:
Una vez más el nombre del archivo que contiene referencias a una
versión vieja de gcc podría tener un nombre diferente, por ejemplo,
config-i686-pc-linux-gnu aunque esté cambiando a i686. Es importante
identificar el archivo por el contenido, no solo el nombre.
|
Listado de Código 2.8: Borrando el archivo de configuración gcc incorrecto |
# rm config-i386-pc-linux-gnu
|
Ahora ejecute los siguientes comandos para actualizar su entorno:
Listado de Código 2.9: Actualizando el entorno |
# env-update && source /etc/profile
|
Verifique que todo esté arreglado:
Listado de Código 2.10: Verificando que las referencias al CHOST viejo hayan sido borradas |
# grep -r 386 /etc/env.d/
|
Si todavía encuentra algo, debe haber saltado algún archivo, trate de
ubicarlo antes de continuar.
Terminando el Cambio
Ahora será necesario hacer emerge otra vez a libtool y ejecutar
/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh.
Debemos asegurar el uso de la versión correcta del gcc (la actual, 4.1.1 y
la arquitectura anterior, i386). Reemplace $CHOST con el CHOST nuevo y la
<gcc-version> con la versión del gcc. Este ejemplo asume un
CHOST i686.
Listado de Código 2.11: Asegurando una librería sana |
# emerge -av1 libtool
# /usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/fix_libtool_files.sh 4.1.1 --oldarch i386-pc-linux-gnu
|
Tal vez quiera reconstruir todos los paquetes instalados:
Listado de Código 2.12: Reconstruyendo world |
# emerge -e world
|
Ahora en teoría, no debería ser necesario hacer esto, pero no podemos
garantizar esto al 100% si no recompila world. Entiendo que al menos
algunos paquetes requieren recompilación, así que:
Listado de Código 2.13: Recompilando python |
# emerge -av1 python
|
Todos los paquetes que usan perl instalan según el directorio CHOST y
por ende hay que recompilarlos. En caso que no haya instalado
qfile, necesitará instalar primero
app-portage/portage-utils.
Listado de Código 2.14: Recompilando los paquetes perl |
# emerge -av portage-utils
# emerge -av1 `qfile /usr/lib/perl* -Cq | sort -u`
|
Si encuentra otros paquetes que requieren recompilación, por favor
hágaselo saber al autor de este documento.
Problemas Comunes
Al actualizar del gcc 3.3 a 4.1 al mismo tiempo que hacer el cambio de
CHOST (de todas formas, por favor no lo haga), un par de usuarios
reportaron paquetes rotos que requirieron recompilación como groff y
courier:
Listado de Código 2.15: Mensaje de error |
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
|
Esto ocurre porque al hacer la actualización, el CHOST no es
exactamente igual al CTARGET y el compilador asume que se trata de una
compilación cruzada. Como consecuencia, no se inserta LDPATH en el
archivo ld.so.conf, lo cual resulta en este error.
Por favor vea nuestra guía de
actualización del gcc para información acerca de qué reconstruir
después de una actualización del gcc.
En algunos raros casos, esto puede romper versiones antiguas de
python también. Esto se puede arreglar agregando
/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (cambie según el
CHOST y gcc anteriores) a /etc/ld.so.conf, ejecutando
ldconfig y luego haciendo emerge libstdc++-v3. Sin
embargo, tal como puede ver, realmente puede evitar encontrarse con
este problema al no cambiar el CHOST y el gcc al mismo tiempo.
Comentarios, sugerencias
Eso debería ser todo, cualquier comentario o sugerencia (si funciona o
no o si se encontraron otros problemas) es bienvenido. Por favor envíe
correo electrónico a Wernfried Haas o haga un post en
este
foro. Mucha de la información en este documento es por cortesía
de vapier, ¡gracias por tu ayuda!
El contenido de este documento, a no ser que se especifique
expresamente, está registrado bajo los términos de la licencia
CC-BY-SA-2.5. Se aplican las
Pautas de
Utilización del logotipo y nombre de Gentoo.
|
