Aggiornare GCC

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Upgrading GCC and the translation is 46% complete.

Other languages:
English • ‎español • ‎italiano • ‎日本語 • ‎한국어 • ‎русский • ‎中文(中国大陆)‎

Questo documento guiderà l'utente durante il processo di aggiornamento di GCC.

Avvio rapido


Questo articolo riguarda l'"aggiornamento" di GCC. Il declassamento di GCC ad una versione minore potrebbe avere effetti indesiderati. Si prega di fare riferimento alla sezione "risoluzione dei problemi" in merito ad alcuni dei problemi più comuni.

La prossima sezione mostra le basi sugli aggiornamenti di GCC (e mostra quanto essi siano facili). Se si ha bisogno, invece, di approfondire tale discorso, vedere GCC Upgrading Explained.

Versione breve

Se si sta aggiornando GCC, non c'è bisogno di altro se non di passare alla nuova versione del compilatore e ricompilare/ricostruire le libtool:

root #emerge -u sys-devel/gcc
root #gcc-config -l
[1] i686-pc-linux-gnu-4.4.5 *
[2] i686-pc-linux-gnu-4.5.3
root #gcc-config 2
root #env-update && source /etc/profile
root #emerge --ask --oneshot sys-devel/libtool

Se si aggiorna GCC da una versione precedente la 3.4.0 (per la serie 3.x.series) o 4.1, si dovrà eseguire anche revdep-rebuild:

root #revdep-rebuild --library 'libstdc++\.so\.5'

Controllare la versione corrente e disinstallare la vecchia:

root #gcc --version
root #emerge --ask --depclean =sys-devel/gcc-4.4.5

E' fatta. Goditi il nuovo compilatore!

Spiegazioni sull'aggiornamento di GCC


L'aggiornamento di GCC è sempre stato mistificato, con suggerimenti che vanno da "Non devi fare niente" a "Dovresti ricostruire l'intero sistema due volte". Molte paure, incertezze e dubbi vengono dalla confusione che circonda l'incompatibilità di ABI. Ma prima di tutto diamo uno sguardo veloce a libtool.

libtool e

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.

The reason we need to rebuild libtool after the upgrade of gcc versions is because of its main purpose: libtool is a toolset that aggregates platform-specific code in a generic interface, allowing applications to build against shared libraries without needing to deal with the platform specific aspects of shared libraries. To fulfill its function properly, the libtool script uses various library locations that have hard-coded gcc version information in them.

ABI changes

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.

Yes, C++, since most incompatibilities occur within the C++ ABI. If you are upgrading to GCC 4.1, or GCC 5.1, you would probably encounter ABI issues. This is also why we use the revdep-rebuild command against the (from GCC 3 to GCC 4.1), or (from GCC 4 to GCC 5.1).

root #revdep-rebuild --library 'libstdc\+\' -- --exclude gcc

So why is this only needed up to GCC 3.4.0/4.1/5.1? That's because from that version onward, GCC uses a forward compatible ABI, which removes the need for rebuilding applications and libraries. Of course, guarantees can never be given indefinitely, but when an incompatibility occurs again, we'll definitely document it here. In that case, the version of the library will probably be increased.

The special case C++11 (and C++14)

While GCC (or more specifically, libstdc++) goes to great lengths to guarantee stability of the ABI, this guarantee does not extend to all parts of C++ within libstdc++. Formally, with versions starting from 3.4, GCC/libstdc++ only guarantees C++98/C++03 ABI stability and not more. This is crucial for packages that depend on C++11. GCC only makes C++11 ABI stability guarantees beginning with version 5.1. This means that switching (even minor) versions of gcc (say from 4.7.3 -> 4.7.4) might cause ABI breakage for binaries built from C++11 code.

For more information and some examples, see:

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. Although it is expected that this improvement is generally only marginal, in some cases (especially CPU intensive applications) this might yield notable improvements.

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 qt-* packages are a nice example on this matter.

Troubleshooting version `GLIBCXX_3.4.15' not found

During updates, you might encounter an error like the following:

CODE GLIBCXX_x.y.z not found
cmake_bootstrap_28021_test: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/
version `GLIBCXX_3.4.11' not found

This means that you are trying to build a package with an older GCC version than 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 previous revdep-rebuild section.

Which packages are known to need a rebuild?

The following table gives the packages that, if installed, need to be rebuilt and why.

Package Rebuild needed because ...
sys-devel/libtool libtool application has hardcoded paths towards GCC internal libraries
sys-devel/llvm depends on exact gcc version, may encounter linking errors with other ebuilds making use of LLVM (e.g. media-libs/mesa) if not rebuilt

See also