Paquetes para reconstruir después de actualizar gcc en sistemas gentoo

¿Qué paquetes deben reconstruirse después de actualizar gccen un sistema gentoo? ¿Es suficiente correr?

# emerge -a --oneshot `equery depends gcc |awk '{print " ="$1}'`

como se sugiere similar para perl en estas preguntas frecuentes ?

TL; DR

Tengo una opinión diferente sobre esto como usuario de Gentoo. Si bien estoy de acuerdo con el enfoque de Peter de "Deje que el sistema decida", no estoy de acuerdo cuando se trata de una actualización ABI . Una actualización ABI es a veces un cambio importante en el comportamiento. En el caso de GCC 4.7, el cambio ABI fue la adopción del nuevo estándar C ++ 11, que también señaló Peter.

Aquí es por qué escribo esta respuesta. Soy un adicto a los estándares. Comencé en el mundo web cuando había alrededor de 4 navegadores diferentes, y una gran cantidad de etiquetas en HTML que solo eran compatibles con ciertos navegadores. En ese momento, todas esas etiquetas aumentaron la confusión, y la OMI hizo que el trabajo fuera más difícil. C ++ se ha estandarizado por este mismo motivo, en resumen, para que pueda compilar el código que yo escribo, y yo puedo compilar el código que usted escribe . Si elegimos no seguir un estándar, perdemos la libertad de compartir.

C ++ 98 ha sido el estándar aprobado durante 13 años. C ++ 11 fue ratificado por el Comité ISO en 2011 y se integró completamente en GCC 4.7. Vea el estado ISO actual y el nuevo estándar ISO .

Por qué deberíamos sentirnos privilegiados como usuarios de Gentoo

Como usuarios de una distribución basada en la fuente, tenemos la oportunidad única de dar forma al comportamiento futuro de un paquete porque lo compilamos antes de usarlo. Como tal, para prepararme para esa oportunidad, creo que se deben ejecutar los siguientes comandos al actualizar al nuevo compilador:

emerge -ev system
gcc-config -l && gcc-config *new compiler name*
env-update && source /etc/profile
emerge -1v libtool
emerge -ev system

El primer paso a través del sistema construye el nuevo compilador, y sus dependencias, con el compilador anterior. El segundo paso a través del sistema reconstruye el nuevo compilador y sus dependencias con el nuevo compilador. Específicamente, queremos hacer esto para que nuestra Build Chain aproveche las nuevas características del nuevo compilador, si los paquetes de Build Chain también se han actualizado ... Algunas personas reemplazan el segundo sistema de paso con el conjunto mundial, aunque yo consideramos que esto es excesivo, ya que no sabemos qué paquetes ya admiten el nuevo estándar, pero queremos que nuestra cadena de compilación se comporte de manera sensata.

Hacer esto al menos al conjunto del sistema, nos prepara para probar cada paquete que compilamos con el nuevo estándar, porque utilizamos una versión continua. De esta manera, añadiendo -std=c++11a CXXFLAGSdespués de actualizar la cadena de construcción nos permite prueba de rotura, y ser capaz de enviar errores, ya sea directamente a nuestra Bugzilla o aguas arriba a los desarrolladores reales por la sencilla razón de:

Hola, tu paquete bla, bla, se rompe usando el nuevo estándar C ++, y he adjuntado mi registro de compilación.

Considero que esto es una cortesía para los desarrolladores, ya que ahora tienen tiempo para prepararse a medida que el estándar se adopta más ampliamente, y el antiguo estándar se elimina gradualmente. Imagine la conmoción por parte del desarrollador si recibió cientos de errores, porque él o ella esperaron hasta que se eliminó el estándar ...

Ninguna otra distribución que conozco puede usar este método ya que los mantenedores de paquetes reales existen como intermediarios antes de que la comunidad de usuarios respectiva pueda usar un parche o actualización. Tenemos mantenedores, pero también tenemos la capacidad de usar un árbol de portage local.

Con respecto a los pensamientos perspicaces publicados en la solicitud de recompensa

No sé si la recompensa fue publicada porque a todos les gustan mis respuestas perspicaces y bien pensadas, pero en un intento de recompensa, intentaré responder a su oferta de recompensa perspicaz y bien pensada. En primer lugar, permítanme decir en respuesta que, como usuario de una distribución basada en fuente, creo firmemente que lo que conecta los puntos son todas las cosas que ha pedido en su solicitud de recompensa. Alguien puede ser un gran programador, pero tiene un cuidado desagradable para el software. Del mismo modo, hay personas que son codificadores de mierda que tienen gran cuidado por el software.

Antes de venir aquí, era un ávido afiche, en los foros de Gentoo . Finalmente me di cuenta cuando comencé a venir aquí que todos tienen cierto grado de talento que pueden usar. Es lo que eligen hacer con él lo que hace la diferencia contributiva. Algunos de nosotros somos grandes escritores (no yo), por lo que si desea contribuir a algún proyecto, pero no puede o no puede escribir código, o corregir errores, recuerde que los grandes escritores pueden escribir excelente documentación o excelentes artículos de Wiki .

El estándar está ahí por otra razón: en una comunidad, se esperan ciertas reglas de sus miembros . Sigue esa declaración aquí también. Si envío una corrección, un parche, una mejora, etc. y no hay estándares, el parche solo funcionará en las situaciones que considero importantes, es decir, si estoy usando whizbang compiler 2.0, y el parche está construido contra whizbang compiler 1.0, fallará. Dado que el esfuerzo es para una comunidad, la comunidad espera que todo funcione en la mayoría de las situaciones, por lo que en lugar de obligar a todos los usuarios a actualizar al compilador 2, puedo estipular en un estándar:

Este paquete opta por permitir la compatibilidad con versiones anteriores con Whizbang Compiler 1.0

De esta forma, como desarrollador, codificador de mierda o no, sé que debo usar o al menos probar con la versión 1.0 del compilador. Como usuario, por otro lado, puedo elegir lo que quiero hacer. Si no estoy contento, puedo solicitar un parche enviando un error u otro extremo de "¡Este software es una mierda!" Y no hacer nada. En cualquier caso, el usuario y el desarrollador entienden el estándar porque está escrito.

Cerrar la brecha toma acción de alguna forma por parte del usuario, y eso requiere todas las cosas que usted me pidió a mí y a los demás para comentar, y debemos confiar en la comunidad de usuarios y sus talentos de todas las formas para cerrar esa brecha. Si eliges ser uno de los usuarios contribuyentes, te aplaudo. Para aquellos de ustedes que eligen estar inactivos, recuerden que si quieren que se arregle algo, los activos necesitan su aporte. Por lo tanto, le digo que no sea tímido al enviar un error o que nos diga que necesitamos actualizar la documentación, y si somos groseros, díganos o busque a alguien más, hasta que encuentre su área de especialización.

Otras lecturas interesantes relacionadas con este tema

1. Los cambios más grandes en C ++ 11 (y por qué debería importarle)
2. C ++ 0x / C ++ 11 Soporte en GCC
3. Noticias, estado y discusión sobre Standard C ++

Depende mucho de qué tipo de actualización de compilador haya realizado. Si ha sido sustancial, entonces todo se debe volver a compilar ^*) debido a posibles cambios en ABI por parte del compilador. En muchos casos no será necesario, pero si sus paquetes dependen de algo como C ++ 11, entonces podría tener problemas; consulte, por ejemplo, las noticias de Gentoo sobre el cambio de ABI en GCC 4.7 o GCC bugzilla .

^*) Tenga en cuenta el énfasis en "recompilar": definitivamente no tiene mucho sentido recompilar (leer, reconstruir) una aplicación Python o Perl porque ha cambiado un compilador de C. A menos que también tenga un componente nativo (que bien podría tener).