Guía de actualización de GCC en Gentoo LinuxEsta guía trata la actualización del GCC. Cambiar a una versión más antigua podría traer efectos secundarios indeseados. Por favor refiérase a la sección Solucionando problemas para algunos de los problemas frecuentemente reportados. La siguiente sección da una introducción rápida a las actualizaciones del GCC (y lo fáciles que son). Si desea leer el razonamiento completo detrás de las actualizaciones del GCC, por favor continue con Explicación de Actualizaciones del GCC. Si está actualizando el GCC, no necesita hacer más que cambiar de versión de compilador y reconstruir libtool:
Si está actualizando el GCC de una versión anterior a la 3.4.0 (de la serie 3.x) ó 4.1, tendrá que ejecutar revdep-rebuild también:
¡Listo! Ahora a disfrutar del compilador nuevo. 2. Explicación de Actualizaciones del GCC Las actualizaciones del GCC siempre han sido rodeadas de un aura de misterio, con sugerencias que van desde "No hace falta hacer nada" hasta "Tendrás que reconstruir el sistema completo, dos veces". La mayoría de estas medias informaciones (FUD) vienen de la confusión que rodea las incompatibilidades del ABI. Antes, unas palabras sobre libtool. libtool y fix_libtool_files.sh Las instalaciones anteriores del GCC en Gentoo requerían ejecutar un comando específico llamado fix_libtool_files.sh. Hace algún tiempo, la ejecución de este comando ha sido integrado en la instalación misma del paquete (a través del eclass llamado toolchain), así que ya no es necesario que los usuarios ejecuten este comando. La razón para la cual necesitamos reconstruir libtool luego de actualizar el GCC es dada su función principal: libtool reune un conjunto de herramientas que agregan código específico según plataforma en un interfaz genérico para construir aplicaciones con librerías compartidas sin tener que manejar aspectos específicos de cada cada una. Para que realice su función correctamente, el guión libtool usa varios puntos en la librería con información fija acerca de versiones del GCC. Un ABI, Interfaz Binaria para Aplicaciones (en inglés Application Binary Interface), es un conjunto de convenciones usadas por todas las herramientas que manejan representaciones binarias de los programas, incluyendo compiladores, ensambladores, enlazadores y soporte al momento de ejecución (fuente: GCC Binary Compatibility). Al cambiar el ABI usado para aplicaciones binarias y librerías, existirá el riesgo de obtener errores de enlazado o programas funcionando incorrectamente si no se reconstruyen todas las librerías que usen el código C++. Si, C++, ya que la mayoría de las incompatibilidades ocurren en el ABI de C++. Por esto usamos revdep-rebuild con la librería libstdc++.so.5.
Asi que, ¿por qué se requiere esto para los GCC hasta la versión 3.4.0/4.1? A partir de estas versiones, GCC usa un ABI compatible a futuro, que elimina la necesidad de reconstruir las aplicaciones y librerías. Por supuesto que no se pueden dar garantía indefinidamente, pero cuando ocurra nuevamente una incompatibilidad, definitivamente lo documentaremos aquí ;-) en cuyo caso la versión del libstdc++.so probablemente aumentará. Algunos juran que al aparecer una nueva versión del GCC, se debe reconstruir hasta el último paquete del sistema. Por supuesto, esto no tiene sentido, ya que de todas formas hay muchas aplicaciones que no usan el GCC en su proceso de construcción e instalación y por ende nunca serían afectados por estos cambios. Sin embargo, esto no significa que estén completamente equivocados: las versiones recientes del GCC suelen incluir soporte mejorado para los conjuntos de instrucciones de los procesadores, lo que podría influenciar el desempeño de algunas aplicaciones positivamente. Aunque se estima que estas mejoras sean generalmente marginales, en algunos casos (especialmente en aplicaciones que usan intensivamente el CPU) podrían traer notables mejoras. Existen también casos conocidos donde un conjunto de paquetes deben ser construidos con el mismo compilador. Aunque la versión de estos paquetes suelen ser aumentada simultáneamente con el compilador (de forma que sean construidos con la misma versión del GCC) el escoger selectivamente reinstalaciones de algunos de estos paquetes puede traer problemas. Los paquetes de qt-* son un ejemplo de esto. libstdc++.so.6: version `GLIBCXX_3.4.15' not found Durante las actualizaciones podría tropezarse con un error como el siguiente:
Esto significa que está intentando construir un paquete con una versión del GCC más antigua que el usado para construir algunas de sus librerías dependientes. ¿Recuerde cuando dijimos que el ABI C++ era compatible a futuro? Esto es cierto, pero asegura solamente que versiones más recientes (o iguales) del GCC pueden ser utilizadas para construir aplicaciones y librerías enlazadas (en comparación con la versión del GCC usado para construir esas librerías). ¿Cuáles paquetes se conocen que requieren reconstrucción? La siguiente table lista los paquetes, que de estar instalados necesitarían ser reconstruidos y por que.
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. |
|