Guía Gentoo de actualización del GCC hasta versión 4.1¿Por que debería actualizar? Bueno, GCC es muy similar a cualquier otro paquete en su sistema, pero un poco más crítico. Debería actualizar GCC en caso de que una nueva versión corrija algún bug que le moleste, se añada una nueva funcionalidad que necesita o si quiere mantener su sistema al día. Si ninguno de los casos mencionados le afecta, puede postergar con seguridad la actualización mientras que su versión de GCC esté soportada por los desarrolladores de Gentoo. Si instala una nueva versión de GCC (como de 3.3.6 a 3.4.5), el sistema no hará uso de ella automáticamente. Tiene que pedir explícitamente el cambio porque el proceso de migración puede que tome algunos pasos adicionales. Si decide no realizar el cambio, Portage continuará usando la versión antigua de su compilador hasta que cambie de parecer o borre el compilador antiguo del sistema. Las actualizaciones no críticas del gcc se hará automáticamente (por ejemplo de 3.4.5 a 3.4.6). Esta guía documentará los pasos necesarios para llevar a cabo una actualización sin contratiempos del compilador usado por su sistema Gentoo. Se dedica una sección específica a la actualización de GCC 3.3 a la versión 3.4 o versiones superiores y problemas con libstdc++. Hay una segunda sección específica destinada a los usuarios que instalan Gentoo por primera vez a partir de stage3 tras haberse liberado una nueva versión principal o no de GCC.
2. Instrucciones generales de actualización
Generalmente hablando, las actualizaciones a versiones que incluyen correcciones de bugs, como de la 3.3.5 a la 3.3.6, deberían ser bien seguras -- tan solo instale la nueva versión, haga que su sistema la use y recompile el único paquete que se ve afectado, libtool. Sin embargo, algunas actualizaciones de GCC hacen que se corrompa la compatibilidad binaria, en tales casos puede que se necesite una recompilación de los paquetes afectados (o incluso todo el conjunto de herramientas y paquetes centrales (system)). Cuando hablábamos acerca de la necesidad de cambiar su compilador a una versión nueva, dijimos que no sucedería automáticamente. No obstante, hay una excepción -- las actualizaciones a versiones que corrigen bugs, como de la 3.3.5 a la 3.3.6, en cuyo caso no utiliza la característica de "multislot" que les permite coexistir en el mismo sistema. Multislot está desactivado por defecto ya que la mayoría de los usuarios no se beneficiará de este.
Para estar completamente seguro que su sistema está en un estado seguro, deberá recompilar el toolchain y luego el sistema completo (world) para hacer uso del nuevo compilador.
Es seguro borrar la versión antigua de GCC en este momento. Si siente la necesidad, por favor ejecute el siguiente comando (como siempre, substituya =sys-devel/gcc-3.4* con la versión de GCC que quiere desinstalar):
3. Actualizando GCC-3.3 al 3.4 La actualización de GCC/3.3 al 3.4 no es tan perfecta como uno quisiera puesto que la ABI (Interfaz de Aplicación Binaria) de C++ cambió entre ambas versiones. Existe un problema con la biblioteca libstdc++ de la que también tendremos que ocuparnos.
Si actualiza del gcc 3.3 al 3.4, tiene dos posibilidades para actualizar su sistema. El primer método es más rápido y requiere del uso de la herramienta revdep-rebuild que es parte del paquete gentoolkit mientras que el segundo método recompila su sistema por completo de forma de hacer uso de las nuevas características de GCC. Es su decisión escoger cuál de los métodos va a seguir. En la mayoría de los casos, el primer método es suficiente. Si actualiza del gcc 3.3 al 4.1, no utilice el método basado en revdep-rebuild, sino una reconstrucción completa del sistema. Este método necesita que primero instale gentoolkit si es que ya no lo ha hecho. Luego actualizaremos GCC y cambiaremos al nuevo compilador. También recompilaremos el paquete libtool para asegurarnos que el toolchain se encuentre en un estado saludable.
Ahora queremos ver qué paquetes revdep-rebuild querrá reconstruir. Luego le diremos a revdep-rebuild que recompile dichos paquetes. Esto puede tomar algo de tiempo, así que tenga paciencia.
Para tener compatibilidad con aplicaciones binarias antiguas en C++ y cualquiera de los paquetes que revdep-rebuild puede haberse saltado, el paquete sys-libs/libstdc++-v3 tiene que ser instalado antes de que desinstale GCC 3.3 de su sistema.
Este método, aunque es mucho más lento, recompila todo su sistema para asegurar que todo se haya recompilado con su nuevo compilador, y por tanto, es más seguro. Primero, actualice GCC y libtool y cámbiese a su nuevo compilador.
Para tener compatibilidad con aplicaciones binarias antiguas en C++ el paquete sys-libs/libstdc++-v3 tiene que ser instalado en su sistema.
Ahora primero recompilaremos los paquetes centrales (system) y luego el sistema completo (world). Esto va a tomar mucho tiempo dependiendo del número de paquetes que tenga instalado, pues recompilará el toolchain entero y los archivos de apoyo del sistema, seguido de cada paquete existente en su sistema. Esto es necesario para asegurar que todos los paquetes hayan sido compilados con el nuevo toolchain, incluyendo el propio toolchain también.
También es seguro borrar las versiones antiguas de GCC en este momento.
4. Actualizar GCC en una primera instalación La actualización de GCC tras haber instalado un sistema a partir de stage3 es un asunto sencillo. Una de las ventajas que tienen los usuarios de instalaciones nuevas es que no tienen una gran cantidad de software instalado que enlace contra la versión antigua de GCC. El siguiente ejemplo es para una actualización de GCC-3.3 a 3.4. Ciertas partes serán diferentes si actualiza desde otras versiones de GCC. Por ejemplo, los nombres de las bibliotecas usados más abajo por revdep-rebuild son específicas a GCC-3.3, así como la necesidad de instalar libstdc++-v3. Si no ha hecho personalizaciones a su sistema, entonces hay que seguir unos pocos pasos para que este quede actualizado a la nueva versión de GCC. Tal como con la actualización de GCC-3.3 a 3.4, hay dos opciones posibles. No obstante, a diferencia de la actualización de GCC-3.3 a 3.4, esta es menos complicada ya que hay pocas diferencias entre ambos métodos. El primer método es más rápido y hace uso de la herramienta revdep-rebuild que es parte de gentoolkit, similar al procedimiento descrito arriba. Usar revdep-rebuild hace que se recompilen solamente los paquetes que realmente están enlazados contra las bibliotecas de GCC, mientras que el segundo método hace que su nueva instalación se recompile por completo usando la nueva versión de GCC y por tanto, toma mucho más tiempo. Este segundo método nunca se necesita y está documentado solo por completitud. Los primeros pasos son comunes a ambos métodos, y deberían ser llevados a cabo por todos los usuarios.
Para tener compatibilidad con aplicaciones binarias antiguas en C++ el paquete sys-libs/libstdc++-v3 tiene que ser instalado en su sistema.
Este método necesita que primero instale gentoolkit si es que ya no lo ha hecho. Ejecutaremos revdep-rebuild para revisar los paquetes instalados y así ver aquellos que necesitamos recompilar, luego los recompilaremos.
Este método, aunque es mucho más lento, recompila todo el sistema para asegurar que todo se haya recompilado con su nuevo compilador. Esto no es necesario, pero es válido si también está haciendo cambios a sus CFLAGS u otras variables del fichero make.conf que causarán efecto en la compilación del sistema. Debido a que estamos llevando a cabo esas acciones después de una instalación inicial, no hay necesidad de recompilar todo el sistema (world) tal como lo haríamos en una actualización de un sistema ya en funcionamiento. Sin embargo, puede hacer una actualización completa en vez de actualizar los paquetes centrales (system), para asegurarse que todos los paquetes están actualizados.
También es seguro quitar las versiones antiguas de GCC en este paso. Por favor, substituya SU-NUEVA-VERSION-DE-GCC con la versión real a la cual se actualizó:
Es importante que desactive distcc durante la actualización. Mezclar versiones de compiladores en sus nodos provocará dificultades. Este no se necesita para ccache pues los objetos de éste serán invalidados de cualquier modo. Siempre use la misma versión de GCC para su núcleo y módulos adicionales de este. Una vez que recompile su sistema completo (world) con el nuevo GCC, los módulos externos (como app-emulation/qemu-softmmu) no funcionarán al cargarse. Por favor, recompile su núcleo con el nuevo GCC para corregir aquello. Si está actualizando en una máquina SPARC, asegúrese de ejecutar silo -f luego de haber completado la actualización completa del sistema (world) para evitar posibles problemas. Si su sistema se queja de algo como: libtool: link: `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool archive, por favor ejecute /usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.3.6 (substituya "3.3.6" con el número de versión que sale en el mensaje de error también $CHOST y <gcc-version> con sus versiones actuales de CHOST y GCC). Si observa error: /usr/bin/gcc-config: line 632: /etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory, entonces intente borrar /etc/env.d/gcc/config-i686-pc-linux-gnu y ejecute gcc-config nuevamente, seguido por source /etc/profile. Solamente haga esto si no tiene configurado algún compilador cruzado. Si un paquete falla durante emerge -e system o emerge -e world , puede reanudar la operación con emerge --resume. Si un paquete falla repetidamente, sáltelo con emerge --resume --skipfirst. No ejecute otras instancias de emerge entre medio o perderá toda la información para reanudar. Si obtiene el mensaje de error spec failure: unrecognized spec option mientras actualiza su compilador, intente volver a su compilador por defecto, deshabilite la variable de entorno GCC_SPECS y actualice nuevamente GCC:
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 logo y nombre de Gentoo. |
|