Upgrading GCC/it

Questo documento Article description::guida gli utenti nel processo di aggiornamento verso nuove versioni di GCC.

Si prega di notare che effettuare il "downgrade" di GCC potrebbe avere degli effetti indesiderati. Riferisciti a troubleshooting per i problemi riportati di frequente

Versione breve
Questa sezione è una rapida introduzione negli aggiornamenti di GCC (e quanto semplici sono). Più dettagli sono dati nella prossima sezione, Spiegazioni sull'aggiornamento di GCC.

Molti aggiornamenti di GCC sono semplici come cambiare la versione del compilatore (qui dalla 5.4.0 alla 6.4.0) e ricompilare/ricostruire :

Controllare la versione corrente e disinstallare la vecchia:

Dopo questo, verifica l'integrità del sistema lanciando revdep-rebuild:

Godetevi il nuovo compilatore!

Spiegazioni sull'aggiornamento di GCC
L'aggiornamento di GCC è sempre stato mistificato, con suggerimenti che vanno da "gli utenti non devono fare niente" a "gli utenti dovrebbero ricostruire l'intero sistema due volte". Molte paure, incertezze e dubbi vengono dalla confusione che circonda l'incompatibilità di ABI, una cosa che ai giorni nostri raramente succede (e quando succede, verrà annunciata). Ma prima di tutto diamo uno sguardo veloce a.

libtool
LA ragione per cui noi dobbiamo ricostruire/ricompilare libtool dopo l'aggiornamento della versione di è causato dal suo scopo principale: "libtool" è un set di attrezzi che aggregano codici specifici della piattaforma in una interfaccia generale, permettendo alle applicazioni di compilare contro le librerie condivise senza dover affrontare gli aspetti specifici della piattaforma delle librerie condivise. Per svolgere correttamente la sua funzione, la script utilizza varie locazioni di libreria che hanno hard-coded informazioni sulla versione di  dentro di loro.

Cambiamenti ABI
Un ABI, o Application Binary Interface (Interfaccia Binaria dell'Applicazione), è un set di convenzioni usate da tutti i tool che si occupano della rappresentazione binaria dei programmi, includendo compilatori, assemblers, linkers, e supporto per il language runtime (source: GCC Binary Compatibility). Quando l'ABI utilizzato per le applicazioni binarie e le librerie viene modificato, rischierai di ottenere errori di linker o programmi malfunzionanti a meno che tu non ricostruisca tutte le librerie che usano il codice C++.

Sì, C++, poiché la maggior parte delle incompatibilità si verificano all'interno dell'ABI C++. Se stai aggiornando da GCC 4.1 o GCC 5.1, probabilmente incontreresti problemi con l'ABI. Per prevenire questo, il comando dovrebbe essere eseguito contro la libreria  quando aggiornando da GCC 3 a GCC 4.1, o  quando aggiornando da GCC 4 a GCC 5.1.

Allora perché è necessario solo con GCC 4.1/5.1? Questo perché da quella versione in poi, GCC usa una forward-compatible ABI, che rimuove la necessità di ricostruire/ricompilare le applicazioni e le librerie. Ovviamente, le garanzie non possono mai essere date a tempo indeterminato, ma quando una incompatibilità avviene di nuovo, lo documenteremo sicuramente qui e pubblicheremo una notizia. In questo caso, la versione della libreria sarà probabilmente incrementata.

Il caso speciale di C++11 (e C++14)
Mentre GCC (o più specificamente, libstdc++) fa di tutto per garantire la stabilità dell'ABI, questa garanzia non si estende a tutte le parti di C++ all'interno di libstdc++. Formalmente, con le versioni a partire dalla 3.4, GCC/libstdc++ garantisce solo stabilità ABI C++98/C++03 e non di più. Questo è cruciale per pacchetti che dipendono su C++11. GCC fornisce solo garanzie di stabilità ABI C++ 11 a partire dalla versione 5.1. Ciò significa che il passaggio di versioni (anche minori) di gcc (ad esempio 4.7.3 -> 4.7.4) potrebbe causare la rottura di ABI per i binari compilati dal codice C++11.

Per ulteriori informazioni e alcuni esempi, vedere:


 * 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

Quali pacchetti sono noti per aver bisogno di una ricostruzione?
The following table gives the packages that, if installed, need to be rebuilt and why.

Some collections of packages need to be built with the same compiler (for example, the various packages). Such packages are usually bumped by package maintainers simultaneously, so they will always be built with the same GCC version. Cherry-picking re-installs on these packages might prove to be troublesome.

Rebuilding everything
Some people swear that they need to rebuild every single package on their system when a new GCC version is made available. Of course, that doesn't make sense, since there are many applications that are not using GCC for their build and install process anyhow, so they would never be affected by such changes.

That, however, doesn't mean they are completely incorrect: newer GCC versions often include better support for the processors' instruction set, which might influence the performance of some applications in a positive way.

Apart from such "benign" benefits, rebuilding everything from scratch may be necessary in some cases to fix problems that don't seem to have any obvious cause.

Some software problems are inherently difficult to diagnose and yet could be solved by simply rebuilding one or more appropriate packages. If such a problem has arisen following a GCC upgrade and persists after using the revdep-rebuild approach described above (and after rebuilding any other obviously relevant packages), a complete system rebuild may be the answer.

The "safest" (but also most time-consuming) way to accomplish this is to use the   option of emerge to rebuild the system set and then the world set:

Users are urged to try this approach before reporting any bugs that might have been caused by a GCC upgrade.

(Note that the commands above will cause the packages in the "system" set to be rebuilt twice, which is necessary to be absolutely certain that every package gets built in the same [presumably] "problem-free" environment. Any problems that remain after doing this are due to either "genuine bugs" that should be reported or poor system configuration.)

rebuild of boost
If needs to be rebuilt, one will get the following error message:

One can rebuild with:

libstdc++.so.6: version `GLIBCXX_3.4.15' not found
During updates, you might encounter an error like the following:

This means that you are trying to build a package with an older GCC version than that with which some depending libraries were built. Remember when we told that the C++ ABI is forward-compatible? That is true, but it ensures only that higher (or same) GCC versions can be used when building applications and linking libraries (compared to the GCC version used to build those libraries).

To rebuild all the packages depending on libstdc++, see the instructions above.