Clang ab dem 4. November Standard-Compiler in FreeBSD 10-CURRENT?

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Wie die meisten Leser dieses Forum sicher wissen, arbeitet das FreeBSD Projekt bereits seit mehreren Jahren daran den Standardcompiler des Systems von GCC 4.2 auf Clang zu wechseln. Neben technischen Erwägungen ist der Hauptgrund, dass neuere GCC-Versionen unter der GPLv3 stehen und daher nicht importiert werden können. Die an der Clang-Integration arbeitenden Entwickler haben nun vorgeschlagen, Clang am 4. November zum Standardcompiler auf i386 und amd64 zu machen. Dies hat eine heftige Diskussion ausgelöst: http://lists.freebsd.org/pipermail/freebsd-toolchain/2012-September/000452.html

Die Entwickler argumentieren:
- Auch wenn es noch keinen Termin für FreeBSD 10.0 gibt, ist nun der Zeitpunkt den Compiler zu wechseln. Denn nur so bleibt genügend Zeit Probleme zu beheben. Zudem ist für ein eventuell gpl-freies 10.0 GCC die größte Hürde.
- Es ist der Punkt gekommen, an dem sich Probleme nur noch finden lassen, wenn man mehr Tester ins Boot holt. Und dies geht am besten, wenn alle Current-Nutzer Clang verwenden.
- Zwar bauen derzeit knappe 20% der Ports nicht mit Clang, doch im letzten Jahr gab es an der Front kaum Fortschritte und auch die lange versprochene Option eines austauschbaren Port-Compilers ist noch nicht in Sicht. Ein Stoß ins kalte Wasser könnte die Sache sehr beschleunigen. Zudem können die Maintainer für ihre Ports GCC erzwingen, wenn Clang keine Option ist.

Es gibt aber auch andere Stimmen:
- Da die Ports auf 10-CURRENT (wieder einmal) de facto unbenutzbar würden, ist es für einen solchen Schritt zu früh.
- So ambitioniert Clang auch sein mag, er ist teilweise noch langsamer als GCC und hat noch einige Bugs. So brechen einige Funktionen in libm. Dies sollte vorher behoben werden.

Ich persönlich finde, dass 10-CURRENT keine Stabilität garantiert und Nutzer dieser wirklich sehr aktuellen Entwicklungsversion genau wissen (sollten), worauf sie sich einlassen. Wenn Clang in FreeBSD 10.0 der Standardcompiler werden soll, ist jetzt die Zeit zu handeln und den Schalter umzulegen. Wenn sich die Hürden als unüberwindbar herausstellen sollten, kann man immer noch die Rolle Rückwärts wagen und auf GCC zurückgehen. Vor allem aber ist der GCC 4.2 keine Option mehr. Die Verbesserungsmöglichkeiten an ihm sind ausgeschöpft, es sei denn man würde forken. Neuere CPU-Optimierungen und Befehlssatzerweiterungen werden nicht unterstützt. Der für viel Geld lizenzierte und aufwändig integrierte neue C++-Stack ist zudem mit dem GCC nicht nutzbar. Vor allem aber haben die Entwickler recht: Ohne einen Stoß ins kalte Wasser wird man Clang niemals wirklich stabilisieren können.
 
Yamagi ich stimme dir zu, daß man einfach mal eine Deadline setzen muß, um auch eine gewisse Motivation zum Wechsel zu generieren. Wenn ich es richtig verstanden habe, soll der GCC per Option auch wieder als Standardcompiler aktiviert werden können. Ein unbestritten dringender Wechsel solch grundlegender Tools (siehe auch pkgng) geht halt nicht immer ganz verlust- und schmerzfrei über die Bühne, aber dafür gibt es doch RELEASE und STABLE.
 
Ich würde mich sehr drüber freuen, wenn dann ein paar Probleme von clang-built-world mehr gesehen werden. Ich nutze im Moment (zumindest auf dem Desktop) clang&libc++, diverse ports bauen nicht. Andere bauen, funktionieren aber nicht (z.B. wine). Vieles lässt sich davon sicherlich schnell beheben, wenn es erstmal genug Entwickler stört. :-)
 
Clang ist weiterhin auch als Port verfügbar. Ansonsten werden alte Versionen durch das erscheinen neuer Versionen ja nicht auf einmal unbrauchbar.
 
Vorgestern habe ich mal meinen 9-STABLE Mailserver auf clang (nur für base+kernel), svn sync (cvs für ports wird wohl nur noch bis 02/2013 unterstützt!), sowie auf pkgng umgestellt.
Bis jetzt läuft alles einwandfrei. :)

Die Ports lasse ich aber noch nicht mit clang kompilieren.
 
nicht so traumatisch/dramatisch!

So "traumatisch" oder dramatisch wie vielfach beschrieben ist es gar nicht.

Viele Ports lassen sich noch immer nicht mit CLANG übersetzen, das ist leider wahr. Problem ist hier nicht "FreeBSD", sondern die Entwicklung "upstream". Einige Ports haben - wie man der aktuellen Kommentierung auf freebsd-toolchain@freebsd.org folgen kann - festkodierte Compiler. Die Quellen bzw. das Bausystem respektiert einfach nicht CC/CXX/CPP. Und das sind schlichtweg Anfangerfehler, die selbst bei Fachinformatikerausbildungen derweil durch gute Schulung nicht mehr passieren dürfen. Dennoch, solche Unbilden sind existent.

Einige vehemente Kritiker sind auf bestimmte Ports angewiesen, die eben nicht unter CLANG compilieren. Daß darunter auch Leute sind, die sich aktiv mit der Entwicklung des OS beschäftigen, verleiht diesen eine höhere Wichtung.

Ich nutze seit über 9 Monaten standardmäßig CLANG als Compiler, für das System als auch für die Ports. Einige unserer Workstations laufen unter FreeBSD 10.0-CURRENT, wie auch meine private heimische Maschine.

Fast alles, was ich zum täglichen Leben und forschen benötige, existiert und läßt sich mit CLANG compilieren. Selbst Klötze wie LibreOffice sind Dank Maintainer bapt@ ohne große Klimmzüge mit CLANG compilierbar. PorstgreSQL 9.2 läuft, Apache 2.22 läuft, PHP53 und diverse andere Projekte ebenfalls. Große Probleme bereiten mir auf allen Plattformen zur Zeit nur einige Großprojekte des USGS, die man im Rahmen planetarer Forschung benötigt - das liegt aber daran, daß sich die Entwickler fast Ausschließlich nur mit GCC (4.1!!!!!) beschäftigen (wie is eigens erleben durfte).

Wie Yamagi bereits schrieb: der Sprung ins kalte Wasser ist dringend notwendig! Dieser Eiertanz um den Basiscompiler der letzten Jahre ist unsäglicher Reibungsverlust und behindert meiner Meinung nach auch Entwicklungen und Erfahrungen mit neuen Prozessorarchitekturen/-merkmalen.

Schlimmer aber als die offenkundigen Hemmnisse sind die verstohlenen: Warum sich mit Problemen beschäftigen, wenn man sie mit dem "Standard" gar nicht hat? Für eher numerisch orientierte Naturwissenschaftler ist FreeBSD aufgrund vieler Rückstände, auch in Fragen der vorhandenen Compiler, kaum noch eine Alternative. Ja, man kann einen > GCC 4.6 installieren, aber damit kommen einige sehr diffizile Probleme an Bord, die man dann erfährt, wenn man sich nicht intensiv mit dem Compiler-Handling in FreeBSD beschäftigt. Das kommen dann, ohne daß ich mich damit beschäftigen will, plötzlich Fehler wegen Inkompatibilitaten zweier Bibliotheken ans Tageslicht etc ...

Jetzt machen sich einige Leute wieder ersnthaft Gedanken darüber, wie man das Bau-System des FreeBSD Systems und seiner Ports so gestalten kann, daß der Compiler ausgetauscht werden kann (siehe Liste freebsd-toolchain@). Das finde ich sehr progressiv, bislang klappte das nicht 100% und ich bin nicht Entwickler genug, um genau zu eruieren, wo die Fallstricke genau liegen - meistens steckt der Teufel im Detail und freeBSD ist ja nur eine Facette des Gesamtmosaik.

Ich mache das im Moment folgendermaßen. Man verzeihe mir, wenn ich Dinge herausposaune, die bereits zum Fundus des FreeBSD Allgemeinwissens gehören - ich jedenfalls habe nur durch viele Emails in den Listen den Weg zu diesen Lösung gefunden.

Also, in /etc/mak.conf stelle ich wie empfohlen den Compiler auf CLANG:

###
### CLANG
###
.if !defined(NO_CLANG)
.if !defined(CC) || ${CC} == "cc"
CC= clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX= clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP= clang-cpp
.if !defined(CXXCPP) || ${CXXCPP} == "cpp"
CXXCPP= clang-cpp
.endif
.endif
## Don't die on warnings
NO_WERROR=
WERROR=
### Don't forget this when using Jails!
#NO_FSCHG=
#
CFLAGS+= -pipe -O3 # -fno-strict-aliasing
COPTFLAGS+= -pipe -O3
#CXXFLAGS+= -stdlib=libc++
.endif


In /etc/make.conf halte ich nur jene "Knöpfe", die das Gesamtsystem betreffen und allgemeine Gültigkeit besitzen.

Am Ende der Datei /etc/make.conf inkludiere ich mit

##
## PORTS building
##
.include "/usr/local/etc/ports.conf"

eine eigene Kreation, die ich unter
/usr/local/etc/ports.conf
verorte (ich mag die *BSD Ordnung und strikte Trennung von Basissystem und "Zusätzen" und verstehe nicht, wieso das Ports System nicht ebenso sauber auf /usr/local/ getrennt wird ...).

Diese Datei enthält jetzt Parameter für Ports, die partout nicht mit CLANG bauen wollen - oder gar mit einem gcc > 4.2, sowas gibt es in meiner Umgebung auch noch:

# GIMP mit GCC 4.6+ bauen
# wegen OpenMP
.if ${.CURDIR:M*/graphics/gimp}
USE_GCC= 4.6+
#CC= cc
#CXX= c++
#CPP= cpp
.endif

# multimedia/dirac/
.if ${.CURDIR:M*/multimedia/dirac}
#USE_GCC= 4.6+
CC= cc
CXX= c++
CPP= cpp
.endif

usw. Wenn ab dem 04. November cc=clang et cetera werden wird, geht das natürlich so nicht mehr, wie beim Port multimedia/dirac, dann wird man auf "USE_GCC=4.2"
zurückgreifen müssen.

Aber so wie gezeigt kann ich eigentlich recht gut leben und steuere die Ports eben dediziert. Das klappt nicht immer, irgendwie ist "USE_GCC=" auch (noch) nicht sauber implementiert, aber viele der schwierigen Ports lassen sich vorerst einmal so zusammensetzen - als einfach Hilfe.

OpenMP erzwingt leider einen Compiler, der OpenMP beherrscht, CLANG ist da leider noch Lichtjahre von entfernt, zwar sollen "Polly" und andere Projekte dem Abhilfe schaffen, aber das wird sich gewiß auch noch über die "Release"-Phase FreeBSD 10 hinausziehen.

Kurzum - ich habe "weniger" Probleme mit einer radikalen Umstellung! Mit ein paar Tricks läßt sich damit leben - ich weiß natürlich nicht, welche Skylla und welche Charybdis auf uns lauern werden. CLANG versalzt einem auch hinsichtlich Leistung die Suppe, das sollte man beherzigen. Zwar ist der Speicherplatzverbrauch und die Compile-Zeit offenbar geringer, wie ein jüngerer "post" in der CURRENT Mailingliste dokumentierte, Steve Kargl, Physiker und Entwickler einger numerischer Add-Ons in der matheamtischen Bibliothek, berichtete jüngst, daß es mit CLANG ein Problem gäbe, das die Rechengenauigkeit betrifft. Angeblich ist das Optimierungs-Backend LLVM der Übeltäter.

Aber erst der konsequente Einsatz von CLANG/LLVM hat dieses Problem den Menschen um freeBSD ins Bewußtsein gerückt und nun fokussieren einige mehr als nur S. Kargl das Problem. Wenn Rufe "nach oben", also Uopstream gen Apple/Lattner laut werden, daß es da ein echtes Problem gibt, wird man sich dessen auch schneller annehmen - dessen bin ich mir sicher.

Darüberhinaus ist FreeBSD 10.0-CURRENT eine Blutwurst - frisch, blutig, neu und noch weit von der Erstveröffentlichung entfernt. Warum also nicht schon sehr früh mit einer Umstellung beginnen?
 
Ich bin auch dafür CLANG als Standard-Compiler für 10-CURRENT einzusetzen. Wer CURRENT nutzt, sollte wissen, auf was er sich einlässt. Außerdem geht das Geeiere so nicht weiter, dann wird es nie was.

c.
 
Schande über mich, aber entschldigt bitte die Frage eines Neulings.

Ich steig bei den Lizenzen nicht wirklich durch, wieso GPLv3 verhindert, dass GCC importiert werden kann.
 
Die Sache ist komplizierter und bewegt sich hart am Rand der berüchtigten Lizenzflamewars. Aber ich versuche es dennoch mal: Lange Zeit - fast 15 Jahre - gab es die GPLv2. Diese Lizenz hatte ihre Eigenarten, vor allem das virale Verhalten ist da zu nennen und war unter FreeBSD-Entwicklern und teilweise auch Anwendern nie besonders beliebt. Aber sie war eine Kröte, die man bereit zu schlucken war, da die unter GPLv2 stehende Software es wert war. Kritiker nannten zudem die "or any later version"-Klausel, die z.B. Linus in weiser Voraussicht für Linux strich. Sie argumentierten beispielsweise, dass theoretisch in einer späteren Version auch alle Rechte an der Software auf einen Dritten übertragen werden könnten.

Mitte des letztens Jahrzehnts passierte dann genau das. Die FSF veröffentliche die GPLv3 mit einigen interessanten und aus Sicht der FreeBSD-Entwickler und vieler Anwender nicht gerade berauschenden Bedingungen. Das sind vor allem die "Tivo-Klausel" und die "Patent-Klausel". Auch da kommerzielle FreeBSD-Nutzer wie Juniper sich stark dafür einsetzten keinen GPLv3-Code in das Basissystem zu importieren und Umfragen ergaben, dass die liberale Lizenz einer der Hauptgründe ist FreeBSD einzusetzen, viel die Entscheidung auf GPLv3-Code zu verzichten. Da die FSF aber bei den GNU-Projekten die "or any later version"-Karte zog, war FreeBSD damit vom Upstream der GNU-Projekte abgeschnitten. Man sah darin allerdings kein großes Problem, da man aus verschiedenen technischen Erwägungen bei den meisten GNU-Tools eh zu Eigenimplementierungen wollte.

Speziell auf die GNU-Toolchain bezogen, wollte man Dinge wie libelf, Linker und Debugger sowieso gegen eigene Tools tauschen, da Importe der Upstream-Versionen durch Unterschiede im Binärformat schon immer sehr haarig waren. Der GCC ist ein guter Compiler, man war aber auf ihn nicht unbedingt gut zu sprechen, da er von Version zu Version fetter, langsamer (die Compile-Zeit, nicht das Ergebnis) und fehlerhafter wurde. Dennoch hätte man sicher nie begonnen GCC zu ersetzen, wenn die GPLv3 nicht gekommen wäre. Im Moment ist die Clang-Umstellung zwar in einer kritischen Phase, aber ich denke, dass Clang sich mittelfristig auszahlen wird. Das LLVM/Clang-Projekt hat große kommerzielle Unterstützung und wird auch in der Linux-Welt sehr genau verfolgt.
 
Ich habe mal gerade gcc und clang etwas C++ Performance des codes an dem ich gerade arbeite verglichen. Anwendung ist zu prüfen ob eine gerade im Kartesischen Raum ein Dreieck schneidet. Das heißt den Gauss Algorithmus auf eine 3x4 Matrix anwenden.

Die Messergebnisse sind in [Millionen Prüfungen/s] angegeben, d.h. größer ist besser:
Code: 
clang -O2: 30.030
clang -O3: 29.240 (liefert falsche Ergebnisse bei anderen Operationen in der Anwendung)
gcc42 -O2: 16.051
gcc42 -O3: 16.129
gcc46 -O2: 26.595 (Segfault in anderem Programmabschnitt)
gcc46 -O3: 21.097 (Segfault in anderem Programmabschnitt)
 
Hallo Yamagi,

danke für die Ausführung.
Jetzt muss ich aber schon blöd fragen: warum möchte man denn die Ports auch auf LLVM/Clang umstellen? Die tangieren das eigentliche Betriebssystem doch in keinster Weise und es dürfte doch daher auch keinerlei Lizenz rechtliche Probleme geben. Sicherlich gibt es Programme wie DHCPd, die man vielleicht zum Betriebssystem dazurechnen darf, aber für solche ließe sich doch im Makefile entsprechend deklarieren, dass LLVM/Clang zum Einsatz kommen soll.

Ich befürchte, dass irgendwann bei einer KDE/Gnome/... Applikation im C/C++-Code eine GCC-Spezialität auftauchen könnte, die sich in LLVM/Clang nur sehr aufwändig umsetzen ließe. Dann hätte man das gleiche Problem wie bei der "Linuxifizierung" von XOrg.

Viele Grüße

JueDan
 
Man möchte die Ports nicht auf Clang umstellen, man muss es. Im Moment gibt es unter FreeBSD systemweit nur einen einzigen Compiler. Der wird irgendwo in den dunklen Tiefen von /usr/share/mk gesetzt und zieht sich sowohl durch das Basissystem, als auch durch die Ports hindurch. Daraus folgt, dass ein Umlegen des Schalters in Richtung Clang sowohl das Basissystem, als auch die Port betrifft. Derzeit ist der einzige Ausweg jedem Port einzeln explizit den GCC als Compiler zu setzen.

Aus diesem Grund reden sich die drei Entwickler vom Clang-Integrationsteam seit etwa zwei Jahren den Mund fusselig, dass FreeBSD eine bessere Infrastruktur benötigt. Im Basissystem soll die komplette Toolchain einfach austauschbar werden. Das ist notwendig, um von Clang nicht oder nur schlecht unterstützte Architekturen weiterhin mit GCC oder sogar einem proprietärem Compiler bauen zu können, selbst wenn er nicht im Basissystem ist. Firmen wie Juniper fordern diese Möglichkeit seit langem. Leider ist dafür die seit Jahren geplante Überarbeitung des Buildsystems notwendig, in deren Rahmen unter anderem von pmake auf NetBSDs bmake gewechselt werden soll. Und die ist zäher als Pech bei Raumthemperatur [1].
In den Ports soll der Compiler wenn möglich global definierbar und weiterhin per Port festlegbar sein. Der Benutzer schreibt sich zum Beispiel "gcc47" in seine make.conf und schon nutzen alle Ports diesen, sofern der jeweilige Port keinen anderen erzwingt. Außerdem sollte ein "Standard-Port-Compiler" unabhängig vom Basisystem-Compiler spezifiziert werden, am besten eine aktuelle GCC-Version. Damit wären die Ports auch nicht mehr zwingend von Compiler-Upgrades im Basissystem abhängig, man würde die Ports ein wenig mehr vom Basissystem entkoppeln. Aber auch an dieser Front gab es im letzten Jahr so gut wie keinen Fortschritt.

Was das Clang-Team nun will ist, Druck aufzubauen. Denn ohne massiven Druck, am besten in Form eines unfreiwilligen Stoßes aller Beteiligten von der höchsten Klippe hinab ins Eismeer, wird es nie was. Da kann man noch 5 Jahre warten. Vor allem, da am Clang auch andere Dingen hängen. Den C++-Stack habe ich ja oben schon erwähnt, aber auch der kommende "bsd-ld" und der "llvm-db" als gdb-Ersatz.

1: http://de.wikipedia.org/wiki/Pechtropfenexperiment
 
Sagt mal, muss ich, wenn ich meine Ports mit Clang testen möchte, das ganze Geschwurbel in die zentrale make.conf packen? Kann ich nicht USE_LLVM=1 setzen oder so? Und geht das auf per-port-basis oder nicht, wegen dem Abhängigkeitsbaum und anderen Symbolen?
 
Es gibt noch alternative Ansätze mein Vorschlag hat einige Vor- und einige Nachteile (mir fällt gerade nicht mehr ein, wer an dem Thema gearbeitet hat). Das Thema ist dann einfach in der Prio nach hinten gerutscht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben