Upgrading GCC/es

Este documento guía al usuario a través del proceso de actualizar GCC.

Introducción
Este documento trata de actualizar GCC. Cambiar a una versión más antigua de GCC podría provocar efectos laterales no deseados. Por favor, eche un vistazo a la sección de resolución de problemas para informarse de algunos problemas de los que se informa frecuentemente.

La siguiente sección ofrece una introducción rápida a las actualizaciones de GCC (y lo fáciles que son). Si desea leer el razonamiento completo detrás de las actualizaciones de GCC, por favor, continue con explicación de actualizaciones de GCC.

Versión corta
Si está actualizando GCC entonces no necesita hacer nada salvo cambiar la versión del compilador y reconstruir libtool:

Si actualiza GCC desde una versión anterior a la 3.4.0 (para las series 3.x) o la 4.1, necesitará tambiér lanzar :

Check the current version and uninstall the old version:

Ya lo tiene. ¡Disfrute del nuevo compilador!

Introducción
GCC upgrading has always been mystified, with suggestions ranging from "You do not need to do anything" up to "You will need to rebuild your entire system twice". Most of this fear, uncertainty and doubt comes from the confusion surrounding ABI incompatibility. But first a quick pointer towards.

libtool y fix_libtool_files.sh
Earlier installments of GCC on Gentoo required you to run a specific command called. Some time ago, the execution of this command has been integrated in the package deployments itself (through the toolchain eclass) so there is no need for users to call this themselves anymore.

La razón por la cual necesitamos reconstruir libtool después de actualizar las versiones de es debida a su función principal: libtool reúne un conjunto de herramientas que agregan código específico en un interfaz genérico permitiendo que las aplicaciones se construyan contra librerías compartidas sin tener que manejar aspectos específicos en cada plataforma de estas librerías. Para que realice su función correctamente, el guión utiliza varias localizaciones en la librería con la versión de  previamente fijada dentro de ella.

Cambios en el ABI
An ABI, or Application Binary Interface, is a set of conventions used by all tools that deal with binary representation of programs, including compilers, assemblers, linkers, and language runtime support (source: GCC Binary Compatibility). When the ABI used for binary applications and libraries is changed, you will risk getting linker errors or malfunctioning programs unless you rebuild all libraries that use C++ code.

Si, C++, ya que la mayoría de las incompatibilidades suceden en el ABI de C++. Si se está actualizando a GCC 4.1 o GCC 5.1 probablemente se encuentren problemas en el ABI. Por ello también se utiliza la orden contra   (desde GCC 3 hacia GCC 4.1), o  (desde GCC 4 hacia GCC 5.1).

Asi que, ¿Por qué se requiere esto para GCC hasta las versiones 3.4.0, 4.1 ó 5.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 la documentaremos aquí. En este caso la versión de la librería probablemente será superior.

El caso especial C++11 (y C++14)
Aunque GCC (o más específicamente libstdc++) trata en la medida de lo posible de garantizar la estabilidad del ABI, esta garantía no se extiende a todas las partes de C++ dentro de libstdc++. Formalmente en las versiones a partir de la 3.4, GCC/libstdc++ únicamente garantiza la estabilidad del ABI de C++98/C++03 y ninguno más. Esto es crucial para los paquetes que dependen de C++11. GCC únicamente garantiza la estabilidad del ABI de C++11 a partir de la versión 5.1. Esto implica que el cambio (aunque sea mínimo) en una versión de gcc (digamos de la 4.7.3 a la 4.7.4) puede causar la ruptura del ABI para los binarios que se han construido con código de C++11.

Para obtener más información y ver algunos ejemplos, echar un vistazo a:


 * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
 * https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475

Reconstruir todo
Algunos juran que al aparecer una nueva versión de 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 GCC en su proceso de construcción e instalación y por tanto nunca serían afectados por estos cambios.

Sin embargo, esto no significa que estén completamente equivocados: las versiones recientes de 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 mejoras notables.

There are also known cases where packages need to be built with the same compiler. Although these packages are usually bumped by package maintainers simultaneously (so that they are always built with the same GCC version) cherry-picking re-installs on these packages might prove to be troublesome. The various packages are a nice example on this matter.

libstdc++.so.6: version `GLIBCXX_3.4.15' not found
Durante las actualizaciones puede que obtenga un error como el siguiente:

Esto significa que está intentando construir un paquete con una versión de 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 segura solamente que versiones más recientes (o iguales) de GCC se pueden utilizar para construir aplicaciones y librerías enlazadas (en comparación con la versión de GCC usada para construir esas librerías).

Para reconstruir todos los paquetes que dependen de libstdc++, echar un vistazo a la sección previa sobre revdep-rebuild.

¿Qué paquetes se sabe que deben reconstruirse?
La siguiente tabla indica los paquetes que si se instalan, se necesitarán reconstruir y el motivo por el cual se necesitan reconstruir.

Ver también

 * Upgrade GCC up to 4.1, the previous version of this document
 * Upgrading from gcc-4.x to gcc-5.x