© Li xuejun, 123RF.com

Was heute als GNU Compiler Collection in fast jeder Linux-Distribution steckt, ist das Ergebnis eines Forks. Das Alternativprojekt Egcs öffnete um die Jahrtausendwende die Entwicklung und siegte.

1983 begründete Richard M. Stallman (Abbildung 1) das GNU-Projekt mit dem Ziel, ein komplett freies Betriebssystem zu schaffen. Um die Software dafür schreiben zu können, suchte er nach einem freien Compiler und stieß an einer niederländischen Universität auf das Free University Compiler Kit. Dessen Autor weigerte sich jedoch mit einer schnippischen Antwort, ihm den Compiler für das GNU-Projekt zu überlassen. Das wiederum spornte Richard Stallman dazu an, einen eigenen, plattformübergreifenden Compiler zu entwickeln.

Abbildung 1: Richard Stallman brauchte für sein GNU-Projekt dringend einen Compiler.

Selbst ist der GNU-Mann

Als Ausgangspunkt durfte er den Pascal-Compiler Pastel vom Lawrence Livermore Laboratory verwenden. Stallman schrieb für ihn zunächst ein C-Frontend und versuchte dann den kompletten Compiler auf andere Rechner zu portieren. Dabei musste er jedoch feststellen, dass der Pastel-Compiler äußerst verschwenderisch mit dem Speicher umging. Das wiederum erschwerte den Einsatz auf kleinen Rechnern – Mitte der 80er Jahre zählte noch jedes einzelne Kilobyte. Notgedrungen begann der GNU-Chef einen komplett neuen Compiler zu entwickeln, bei dem er immerhin sein C-Frontend weiterverwenden konnte.

Bis die erste Betaversion das Licht der Welt erblickte, sollten allerdings noch drei Jahre vergehen. Zwischenzeitlich arbeitete Richard Stallman am Texteditor Emacs und gründete die Free Software Foundation (FSF). Sie sorgte für die finanziellen Mittel und stellt auch noch heute die Infrastruktur für die Compiler-Entwickler bereit.

Am 22. März 1987 kündigte Richard Stallman schließlich seinen GNU C Compiler, kurz GCC, über die Projekt-Mailingliste an [1]. Der Compiler unterstützte den kompletten Ansi-C-Standard und führte bereits zahlreiche Optimierungen durch, beispielsweise erkannte er unerreichbare Anweisungen. Code erzeugte der GCC für Sun-3-Workstations mit 68020-Prozessor sowie Vax-Maschinen, ließ sich aber leicht auf andere Systeme mit 32-Bit-Prozessor portieren.

Wer den GCC nicht über den FTP-Server herunterladen konnte, durfte ihn auch auf einem Magnetband anfordern – gegen eine Versandgebühr von 150 Dollar. Gleichzeitig bat Stallman alle Nutzer darum, Fehler zu suchen und zu melden. Die korrigierte Version 1.0 erschien rund einen Monat später. Rasch entstanden weitere Portierungen, die mitunter sogar schnellere und bessere Ergebnisse produzierten als die mit den jeweiligen Systemen gelieferten kommerziellen Compiler. Schon im ersten Jahr lernte GCC auch C++ übersetzen, Ende 1987 erschien bereits Version 1.16 [2].

Besonders engagiert zeigte sich das Unternehmen Cygnus, das sein Geld mit kommerziellem Support für den GCC und den zugehörigen Tools verdiente. Cygnus betreute unter anderem den Debugger und die GNU Binutils. Unter dem Namen GNU Pro verkaufte die Firma sogar ein recht bekanntes Komplettpaket in einer Schachtel. Vor allem Cygnus-Mitbegründer Michael Tiemann trieb die Entwicklung des GCC maßgeblich voran [3]. Zusammen mit der FSF startete Cygnus 1991 die Arbeit an der überholten GCC-Version 2, die im Februar 1992 erschien.

Rührige Eier

Ab Mitte der 1990er Jahre verlangsamte sich das Veröffentlichungstempo zusehends. Stallman und die FSF wollten den Compiler vor allem stabiler machen, Neuerungen standen immer weniger im Fokus. Die eigentliche Weiterentwicklung fand deshalb weitgehend hinter verschlossenen Türen in einem kleinen Entwicklerteam statt. Andere Nutzer durften lediglich Verbesserungen vorschlagen. Unter diesem Vorgehen litt vor allem der C++-Compiler, dessen Ausbau nur schleppend vorankam.

Die unter anderem auch dank Linux extrem rasch gewachsene externe Programmierergemeinde wollte die Entwicklung jedoch beschleunigen und viele weitere Features einbringen. Die unterschiedlichen Sichtweisen gipfelten 1997 schließlich in einem heftigen Streit auf der GCC-Mailingliste.

Irgendwann wurde es einigen frustrierten Entwicklern zu bunt: Unter der Führung von Cygnus schufen sie ihre eigene Variante des Compilers namens Egcs (ausgesprochen “Eggs”, Eier, [4]). Sie sollte vor allem auch die bis dahin aus der Not entstandenen kleineren GCC-Forks wieder zusammenführen. Die erste Version von Egcs basierte auf GCC 2.8, erschien im Dezember 1997 und enthielt vor allem zahlreiche Optimierungen.

Das Entwicklungsmodell des Egcs mit öffentlichen Mailinglisten, Bugtracker und frei zugänglichem Code-Repository zog zahlreiche Programmierer an, was wiederum die Entwicklung beschleunigte. Ab 1998 übernahm ein unabhängiges Steering Committee die Aufsicht über das Egcs-Projekt [5]. Es sollte nicht nur wichtige Richtungsentscheidungen treffen, sondern vor allem verhindern, dass einzelne Personen oder Organisationen die Kontrolle über das komplette Projekt an sich reißen. Mitglieder des Komitees waren neben GCC-Entwicklern auch Nutzer des Compilers, zum Beispiel die Kernelentwickler, die ein großes Interesse an der Fortführung des Projekts hatten [5].

Der Coup

Während der neue Egcs rasch an Zuspruch gewann, verlor der alte GCC zusehends Nutzer und Mithelfer, auch Linux-Distributionen begannen langsam auf Egcs umzuschwenken. Linus Torvalds bevorzugte allerdings den alten GCC, seine offiziellen Kernel waren weiterhin auf ihn zugeschnitten.

Diese Unterstützung half Richard Stallmans Compiler jedoch nicht mehr: Anfang 1999 zog die FSF die Notbremse, stellte die Entwicklung des GCC ein und machte den Konkurrenten Egcs zum offiziellen GNU-Compiler. Gleichzeitig erhielt der Egcs den neuen Namen GNU Compiler Collection, der absichtlich wieder zum bekannten Akronym GCC führt. Aus der letzten Version des Egcs entwickelte sich schließlich die beliebte Versionsreihe 2.95.x.

Die etablierte Kontrolle und Steuerung durch das Steering Committee blieb bis heute erhalten. Diesem gehören derzeit unter anderem der Österreicher Gerald Pfeifer von Suse und der Deutsche Marc Lehmann von der Nethype GmbH an. Richard Stallman zählt ebenfalls zu den Mitgliedern des Steering Committee [5], in das technische Tagesgeschäft ist er jedoch nicht involviert.

Krise überstanden

Die Abspaltung des Egcs war die einzige große Krise in der Geschichte des Compilers, wie der langjährige GCC-Entwickler Gerald Pfeifer bestätigt: “GCC 2.95 wurde vor 14 Jahren releast und hat formal die Egcs-Abspaltung beendet. Das ist in dieser Branche doch schon eine recht lange Zeit, und Konflikte auch nur ähnlicher Größenordnung hat es seit damals nicht gegeben. Natürlich sind GCC-Entwickler, wie andere auch, manchmal stark von der Richtigkeit ihres Ansatzes oder Falschheit eines anderen Ansatzes überzeugt und argumentieren auch so. Grobheiten oder Flames wie beim Linux-Kernel sind aber kaum anzutreffen.”

Während 1999 der GCC neu durchstartete, fusionierte Cygnus mit Red Hat. Der Firmenname verschwand jedoch nicht ganz: 1995 begann Cygnus die GNU-Toolchain unter dem Namen Cygwin auf Windows zu portieren. Unter diesem Namen firmiert das mittlerweile maßgeblich von Red Hat betreute Projekt noch immer [6]. Von der Version 2.95.2 bis zur nächsten großen GCC-Version 3.0 dauerte es ganze zwei Jahre.

Red Hat konnte die lange Entwicklungszeit offenbar nicht abwarten und veröffentlichte 2000 eigenmächtig die Version 2.96. Sie basierte auf einem Entwickler-Snapshot der Version 2.95, dem Red Hat einige Patches verpasste. Die von diesem Compiler gelieferten Ergebnisse waren teilweise nicht mit den Kompilaten des offiziellen GCC binärkompatibel. Zum Glück verschwand die Version 2.96 so schnell, wie sie gekommen war.

Feste Termine

Die lange Entwicklungszeit bis zur Version 3.0 animierte das GCC-Projekt dazu, den Arbeitsablauf zu überdenken und vor allem feste, vorhersehbare Release-Termine vorzugeben [7]. Aktuell verläuft die Entwicklung in drei Phasen: In der ersten dürfen die Entwickler am Compilerpaket beliebige Änderungen vornehmen beziehungsweise neue Features einreichen. Dafür haben sie mindestens vier Monate Zeit. Größere Modifikationen am Compiler müssen die Entwickler zunächst in einem eigenen Entwicklungszweig vornehmen.

In der zweiten Phase, die mindestens zwei Monate dauert, dürfen die Entwickler nur noch Fehler beheben und Änderungen einreichen, die keine anderen Teile des Compilers beeinflussen. Den Abschluss bildet eine Stabilisierungsphase, in der das Projekt nur noch Regressionen behebt und die Dokumentation verbessert. “Praktisch gesehen dauern diese Phasen zurzeit doch jeweils etwas länger, sodass wir etwa bei einem Jahresrhythmus stehen”, so Gerald Pfeifer. Die Kommunikation der GCC-Entwickler untereinander erfolgt nach wie vor primär über die zahlreichen Mailinglisten ([8], Abbildung 2) sowie einen IRC-Kanal. Darüber hinaus treffen sich die Entwickler einmal im Jahr auf der Konferenz Cauldron, die 2012 den GCC Summit beerbte.

Abbildung 2: In der Version 2.95 der Compiler Collection fanden die Egcs- und GCC-Fraktionen wieder zusammen.

Fehler sammelt das Projekt in einem Bugzilla-Bugtracker [9], der vor einigen Jahren den Konkurrenten Gnats abgelöst hat. Allein 2013 haben bisher rund 300 Personen zur Entwicklung der Compiler Collection beigetragen. Der GCC-Webauftritt führt Hunderte weitere Mitwirkende auf, die einen Beitrag geleistet haben, von einer kleinen Korrektur bis zur Portierung auf eine neue Architektur [10].

Standhaft

In der Vergangenheit musste die GNU Compiler Collection immer wieder Kritik von ihren Anwendern einstecken. Die kommt immer dann, wenn die GCC-Entwickler Altlasten entfernen. Das sind meist Sprachelemente, die aus den Standards herausgefallen sind, sich als überflüssig erwiesen haben oder die der GNU Compiler (bewusst) anders als im Standard beschrieben interpretiert hat. Letzteres traf in der Vergangenheit vor allem C++-Programmierer [11]. Aber auch Kommandozeilen-Parameter entfallen häufig, die Optimierungs-Parameter für alte Pentium-Prozessoren sind nur ein Beispiel [12].

Diese Aufräumaktionen können immer wieder das Übersetzen älterer Software erschweren oder gar blockieren. Die wenigsten Probleme bereitet Quellcode, der strikt den offiziellen Sprachstandards folgt. Dieser lässt sich meist auch noch Jahre später problemlos übersetzen. Das bestätigt Gerald Pfeifer: “Standardkonformer Code kompiliert erfahrungsgemäß über viele Versionen von GCC hinweg, wobei es bei C++ und Fortran eher zu Problemchen kommt als bei C. Der Großteil der Probleme, die auftraten, kann relativ einfach behoben werden, durch die Ergänzung eines fehlenden »#include« im Code oder eines »using« bei C++. Wie wir bei größeren Paketmengen sehen, ist GCC an sich sehr gut kompatibel, besser als andere Compiler, die stattdessen testweise verwendet wurden.”

Auch die Kritik an der schleppenden Unterstützung von neuen Sprachstandards darf man differenzierter betrachten. Insbesondere gilt es, zwischen den verschiedenen Frontends zu unterscheiden: Während GCC den C++11-Standard schon recht früh in weiten Teilen beherrschte, stagniert die Java-Entwicklung zugunsten des Open JDK.

Ausblick

Mit LLVM kratzt ein recht leistungsfähiger Konkurrent zunehmend an den Marktanteilen des GCC. Immerhin, ein wenig die Nase vorn hat der GNU-Compiler noch: GCC unterstützt seit dem 22. März 2013 mit der Version 4.8 den kompletten C++11-Standard (Abbildung 3). Clang/LLVM hat dieses Ziel mit der Release 3.3 erst drei Monate später erreicht.

Abbildung 3: Der GNU-Compiler unterstützt seit Version 4.8 vom März 2013 den neuen Sprachstandard C++11.

In der letzten Zeit fordern Entwickler vermehrt, GCC zu modularisieren [13]. Ein weiteres Problem ist der mittlerweile auf über 250 MByte angewachsene Quellcode, der viele neue Entwickler davon abschreckt, in ihn einzutauchen. Die Übersicht soll eine Reimplementierung in C++ lösen, welche die Entwickler mit der Version 4.8 teilweise schon in Angriff genommen haben [14].

Trotz dieser Probleme bleibt der GNU Compiler auch 26 Jahre nach seiner ersten Release extrem beliebt. Er kommt in unterschiedlichen Firmen zum Einsatz, und es gibt kaum eine Linux-Distribution, die ihn nicht standardmäßig ausliefert. Für fast jedes Betriebssystem existiert eine Portierung. Mit ein und demselben Compiler können Programmierer ihre Software auf ARM-Rechnern, x86-Systemen oder sogar Mainframes übersetzen. Die Zukunftsaussichten eines Compilers hängen jedoch maßgeblich davon ab, wie schnell er neue Sprachstandards unterstützt und wie effizient die ausgespuckten Programme laufen.

Dank der zahlreichen GCC-Entwickler und vieler Ideen dürften die nächsten 26 Jahre in jedem Fall äußerst interessant werden. Dem stimmt auch Gerald Pfeifer zu: “Das Spannende an GCC ist doch, dass sich laufend etwas tut an der einen oder anderen Front.” (mhu)