Upgrading GCC/de

Dieses Dokument Article description::beschreibt den Prozess der Aktualisierung auf neuere Versionen von GCC.

Es ist zu beachten, dass das Aktualisieren von GCC auf eine ältere Version zu ungewollten Seiteneffekten führen kann. Der Abschnitt zur Fehlerbehebung beschreibt einige häufig gemeldete Probleme.

Kurzfassung
Dieser Abschnitt beschreibt das Aktualisieren von GCC (und wie einfach es ist) in Kurzfassung. Eine ausführliche Erklärung ist im nächsten Abschnitt,, zu finden.

Die meisten GCC-Aktualisierungen lassen sich einfach durch einen Wechsel der Compiler-Version (hier von 5.4.0 auf 6.4.0) und eine Neuinstallation von durchführen.

Nach einer Überprüfung der aktuellen Versionsnummer kann die alte Version deinstalliert werden:

Anschließend sollte die Systemintegrität mittels revdep-rebuild verifiziert werden:

Viel Spaß mit dem neuen Compiler!

GCC-Aktualisierung erklärt
Die Aktualisierung von GCC ist seit jeher ein verwirrendes Thema, für das Empfehlungen von "Benutzer müssen überhaupt nichts tun" bis hin zu "Benutzer müssen das gesamte System zweimal kompilieren" kursieren. Die Hauptursache dieser Angst und Unsicherheit ist ABI-Inkompatibilität, etwas, das heutzutage selten passiert (und wenn doch, dann wird es angekünfigt). Aber zunächst zu einem kurzen Hinweis zu.

libtool
Die Tatsache, dass libtool nach einer GCC-Aktualisierung neu installiert werden muss, liegt in seinem Hauptanwendungszweck begründet: "libtool" ist Werkzeugkasten, der plattformspezifische Anweinsungen in einer generischen Schnittstelle aggregiert, gegen die Anwendungen dann gemeinsam genutzte Bibliotheken bauen können, ohne die plattformspezifischen Aspekte dieser berücksichtigen zu müssen. Um diese AUfgabe hinreichend zu erfüllen, enthalten die von verwendeten Skripte hartcodierte -Versionsinformationen.

ABI-Änderungen
Die ABI, also das "Application Binary Interface" (auch Binärschnittstelle), ist ein Satz von Konventionen, der von allen Werkzeugen benutzt wird, die mit binären Repräsentationen von Programmen arbeiten, also beispielsweise Compilern, Assemblern, Linkern und der Laufzeitunterstützung von Sprachen (Quelle: GCC-Binärkompatibilität). Wenn die von binären Anwendungen und Bibliotheken benutzte ABI sich ändert, besteht das Risiko von Linker-Fehlern und Fehlfunktionen in Programmen, es sei denn, alle Bibliotheken werden neu kompiliert, die C++-Code benutzen.

Ja, C++, denn die meisten Inkompatibilitäten kommen in der C++-ABI vor. Wird auf GCC 4.1 oder GCC 5.1 aktualisiert, so ist mit ABI-Problemen zu rechnen. Um dies zu verhindern, sollte der Befehl gegen die Bibliothek  ausgeführt werden, wenn von GCC 3 auf GCC 4.1 aktualisiert wird, bzw. , wenn von GCC 4 auf GCC 5.1 aktualisiert wird.

Warum ist dies nur für bis zu den Versionen GCC 4.1/5.1 erforderlich? Das liegt daran, dass GCC ab dieser Version eine vorwärtskompatible API benutzt, mit der das neukompilieren von Anwendungen und Bibliotheken nicht mehr nötig ist. Natürlich kann eine solche Garantie nicht für immer gelten, aber wenn es erneut zu einer Inkompatibilität kommen sollte, wird diese hier dokumentiert und auch ein zugehöriges News Item wird herausgegeben. In diesem Fall wird die Version von vermutlich erhöht.

Der Sonderfall C++11 (und C++14)
Obwohl GCC (oder besser gesagt, libstdc++) sehr darum bemüht ist, die Stabilität der ABI aufrechtzuerhalten, bezieht sich dieses Versprechen nicht auf alle Teile von C++ in libstdc++. Früher, in Versionen ab 3.4, garantierten GCC und libstdc++ die ABI-Stabilität nur für C++98/C++03 und nicht mehr. Das ist entscheidend für Pakete, die von C++11 abhängen. GCC garantiert eine Stabilität der C++11-ABI nämlich erst ab Version 5.1. Das bedeutet, dass selbst ein Wechsel der Nebenversion von GCC (beispielsweise 4.7.3 -> 4.7.4) eine ABI-Inkompatibilität für Pakete verursachen kann, die aus C++11-Quelltext kompiliert werden.

Für weiterführende Inhalte und einige Beispiele, siehe:


 * 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

Welche Pakete müssen neu kompiliert werden?
Die folgende Tabelle enthält Pakete, die, falls installiert, neu kompiliert müssen, und warum dies so ist.

Einige Gruppen von Paketen müssen mit demselben Compiler gebaut worden sein (beispielsweise die verschiedenen -Pakete). Solche Pakete werden von den Paket-Maintainern üblicherweise gleichzeitig aktualisiert, sodass sie immer mit derselben GCC-Version gebaut werden. Pakete aus einer solchen Gruppe selektiv neu zu kompilieren kann sich als problematisch erweisen.

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.

Weiterführende Informationen

 * Upgrading GCC up to 4.1, die vorherige Version dieses Dokuments
 * Upgrading frmo gcc-4.x to gcc-5.x
 * Fedora's 'Änderungen/GCC6' Wiki-Seite