Clang unter Windows als Produktivsystem

[Jonathan]

Moin,
ich will ja schon lange einmal Clang ausprobieren, aber wann immer ich recherchiert habe schien es noch mehr oder weniger experimentell zu sein. Wie sieht es da jetzt mittlerweile aus? Es gibt schon offizielle Anleitungen, um Clang mit VC zu benutzen, was natürlich hübsch ist. Was mich jetzt interessierne würde: Wie viel Arbeit ist das ungefähr? Kommt man da mit einem langen Nachmittag aus? Muss man sämtliche Abhängigkeiten, die man irgendwo benutzt auch neu compilieren?

Was dann aber noch interessanter ist: Welche Vorteile würde Clang konkret bieten? Man hört ja, dass die Architektur hübsch sein soll, dass es flott ist, schöne Fehlermeldungen produziert und Möglichkeiten hat, Codeanalyse-Tools umzusetzen. Aber wie viel davon kommt im Moment schon beim Endanwender an? Lohnt es sich, ein komplexes Projekt mit vielen Abhängigkeiten auf Clang umzustellen? Benutzt ihr Clang schon als Standardcompiler oder eher so zum rumspielen und für Assembler-Spielereien?

[Schrompf]

Ich kann Dir dazu nix sagen, aber ich bin auch sehr interessiert an dem Thema.

[Spiele Programmierer]

Also ich habe mal Clang selbst kompiliert und wollte ein bisschen damit herumprobieren:
Bei mir ist es daran gescheitert, dass ich keine brauchbare C(++) Standardlib gefunden habe. Libc++ ist leider noch nicht so weit.

Warum ich das machen wollte/will, war hauptsächlich um ungehemmt C++11 und C++14 verwenden zu können, wo der MSVC teilweise noch sehr hinterher hängt. Außerdem gibt es ein paar andere Nette Dinge. Es gibt wohl zum Beispiel eine Implementierung für Module. Wenn du das sinnvoll betreiben willst, denke ich schon, dass es sinnvoll ist das Projekt nochmal vollständig damit zu betreiben. Möglicherweise kann man Interop betreiben, aber da wird es Abstriche geben. (LTGC, mehrere Libs, ...)

[Krishty]

Ausprobieren! Als ich es zuletzt versucht hatte, schaffte Clang noch nicht Linken / Exception Handling und unterstützte nur 32-Bit x86. Seitdem versuche ich mit Visual C++ produktiv zu sein statt mich weiter mit Compiler-Wahl herumzuschlagen (Zeitmangel). Wer mehr Zeit hat als ich: Unter http://llvm.org/builds/ den Windows-Installer herunterladen; installieren; in den Projekteinstellungen als Platform Toolset LLVM auswählen; testen!

Auch wenn es am Ende nicht funktioniert findet man trotzdem zwei, drei Schwachstellen im Quelltext allein durch die besseren Warnungen.

[NytroX]

Hi,

ja, ich hatte es auch nicht sinnvoll hinbekommen.
Die neuen C++ Features waren auch bei mir ausschlaggebend. Ich benutze auch weiterhin VS, weil ich nach langem frickeln auch nix brauchbares zustande gebracht hatte.

Ist mir aber ehrlich gesagt nicht klar, was die da immer machen. Es gibt genau EINE interessante Windows-Platform für Entwickler, nämlich Win7+ x64.
Ich frage mich warum man da nicht mal einen einfachen Installer hinbekommt, der einfach mal out-of-the-box funktioniert (und das ist nicht nur bei Clang so).

[Krishty]

Ich frage mich warum man da nicht mal einen einfachen Installer hinbekommt, der einfach mal out-of-the-box funktioniert (und das ist nicht nur bei Clang so).

Naja; es sind Expertensysteme. Wer an Clang arbeitet kann es auch kompilieren und diskutiert nur mit Leuten die es auch selber kompilieren und nimmt deshalb implizit an, dass es jeder, der es benutzt, selber kompilieren kann. Außerdem ist die Aufgabe, eine funktionierende Installationsroutine zusammenzustellen, nicht halb so reizvoll wie z.B. einen neuen Optimizer-Pass zu implementieren.

Unter Mac IST es ein einfacher Installer (Xcode). Aber halt nur, weil Apple Geld reinpumpt damit die nervigen Aufgaben erledigt werden. Wie auch Visual C++ recht einfach zu installieren ist weil Microsoft Geld reinpumpt, damit die nervigen Aufgaben erledigt werden.

[Jonathan]

Ich habe mich nochmal kurz damit befasst. Die Installation ist tatsächlich kinderleicht, die Binaries funktionieren einfach so, ohne das man etwas kompilieren oder einrichten müsste. Danach kann man clang in VC auswählen und loslegen.
Allerdings kompiliert die Standardbibliothek wegen irgendwelchen VC spezifischen Features nicht. Das wurde ja schon angesprochen und es gibt ja auch irgendwo alternative Implementierungen die man einrichten könnte. Das größere Problem ist aber, das boost nicht kompiliert.

Was ich auf jeden Fall schon sehen konnte, waren die detaillierteren Fehlermeldungen von clang. Das gefällt mir im Grunde sehr gut, aber da ich hunderte "falsche" Fehler und Warnungen habe ist auch das nicht besonders nützlich.

Was ich aber jetzt machen werde, ist ein paar LLVM-Tools zu benutzen. Als allererstes include-what-you-use. Mal sehen wie gut das funktioniert und wie viel es finde.

[Krishty]

Endlich. Nach fast einem Jahr Anpassung kompiliert meine Engine in Visual Studio nun auch mit Clang.

Und schon scheinen alle Gleitkommaberechnungen kaputt zu sein und der Bildschirm ist voll buntem Müll. Der Debugger kann keine Variableninhalte anzeigen. Und vor jedem Ausführen wird jede Datei neu kompiliert. Wird eine schöne Zeit.

Nachtrag: Ach schön. Wo man unter Visual C++ ein __m128 vector = { d, c, b, a }; hatte, hat man jetzt ein float __attribute__((vector_size(16))) vector[4] = { a, b, c, d };. Jetzt läuft die Debug-Version tatsächlich fehlerfrei :)

Nachtrag 2: Mir scheint es, als ob weiterhin Microsofts Linker benutzt wird. Ich bekomme jedenfalls kein vernünftig optimiertes Programm :(

[Spiele Programmierer]

SSE Intrinsics und Strukturen sollten unter Clang unterstützt werden. Nur diese Art der Initialisierung nicht, weil die Art wie "__m128" intern aufgebaut ist, wohl eine Microsoft spezifische Extension ist. Außerdem habe ich mir sagen lassen, dass es in einigen Fällen zu ineffizienten Code führt. Die Art es richtig zu machen, wäre eigentlich "_mm_set_ps" bzw. "_mm_setr_ps".

Soweit ich weiß ist es in der Tat so, dass LLVM/Clang immer den Plattform spezifischen Linker verwendet. Es gibt einen Linker im LLVM Projekt, LLD. Der funktioniert angeblich sogar auch unter Windows, hat aber scheinbar generell noch keine Unterstützung für
Debugginginformationen jedweder Art.

LLVM besitzt abseits vom Linker aber durch sein Design die Möglichkeit zur Link Time Code Generation. Dazu sollten dann auch alle "guten Optimierungen" gehören - selbst mit dem Microsoft Linker.

Ich persönlich bin auch immer noch kein Fan davon, dass man mit LLVM/Clang scheinbar begonnen hat, alle "Fehler"(bzw. auch Inkompatibilitäten) von Microsofts Compiler zu kopieren.

[Krishty]

SSE Intrinsics und Strukturen sollten unter Clang unterstützt werden. Nur diese Art der Initialisierung nicht, weil die Art wie "__m128" intern aufgebaut ist, wohl eine Microsoft spezifische Extension ist. Außerdem habe ich mir sagen lassen, dass es in einigen Fällen zu ineffizienten Code führt. Die Art es richtig zu machen, wäre eigentlich "_mm_set_ps" bzw. "_mm_setr_ps".

Ja, aber das funktioniert nicht mit statischen Daten. Wenn du dir z.B. eine Bitmaske für abs() baust, sorgt _mm_set_ps() in Visual C++ für eine dynamische Initialisierungsfunktion statt eines einfachen Dateneintrags. *spuck*

Soweit ich weiß ist es in der Tat so, dass LLVM/Clang immer den Plattform spezifischen Linker verwendet. Es gibt einen Linker im LLVM Projekt, LLD. Der funktioniert angeblich sogar auch unter Windows, hat aber scheinbar generell noch keine Unterstützung für Debugginginformationen jedweder Art.

Interessant ist, dass ich in der LLVM-Version zusätzliche Segmente mit Debug-Informationen gefunden habe. Auch scheint der Microsoft-Linker aus Clang-Eingaben keine ungenutzten Symbole mehr zu filtern, sondern jede Funktion aus jedem Übersetzungsmodul landet garantiert in der EXE (möglicherweise sind sie nun durch Clangs Debug-Informationen referenziert?). Da gibt es noch eine Menge zu erforschen.

LLVM besitzt abseits vom Linker aber durch sein Design die Möglichkeit zur Link Time Code Generation. Dazu sollten dann auch alle "guten Optimierungen" gehören - selbst mit dem Microsoft Linker.

Ja genau, aber Visual Studio bietet dafür keine Konfigurationsmaske an. Um da heranzukommen, werde ich gleich wieder ClangVSX installieren. Vielleicht habe ich damit mehr Glück. Sonst muss ich eben ganz hart über die Kommandozeile gehen :(

Ich persönlich bin auch immer noch kein Fan davon, dass man mit LLVM/Clang scheinbar begonnen hat, alle "Fehler"(bzw. auch Inkompatibilitäten) von Microsofts Compiler zu kopieren.

Das gleiche kann man doch über GCCs abartige Syntax-Spielereien sagen. Was sich übrigens selber nicht durchgesetzt hat, weil jede neue GCC-Version alten Quelltext kaputtgemacht hat. Wäre Clang nicht kompatibel, wäre es heute wieder tot. Lies Joel on Software über Eintrittsbarrieren.

[Spiele Programmierer]

Ja, aber das funktioniert nicht mit statischen Daten. Wenn du dir z.B. eine Bitmaske für abs() baust, sorgt _mm_set_ps() in Visual C++ für eine dynamische Initialisierungsfunktion statt eines einfachen Dateneintrags. *spuck*

In Clang ist das aber anders. Wenn du es also mit Intrinsics machst, hast du 100% der Effizienz in Clang und bist trotzdem wenigstens noch zu Visual Studio kompatibel. Ich habe es gerade sogar mal vorsichtshalber nochmal ausprobiert, es gibt keine Laufzeitinitialisierung in Clang als auch in GCC. (Getestet mit einem aktuellen Build von Clang und GCC 4.6.2)

Das gleiche kann man doch über GCCs abartige Syntax-Spielereien sagen. Was sich übrigens selber nicht durchgesetzt hat, weil jede neue GCC-Version alten Quelltext kaputtgemacht hat. Wäre Clang nicht kompatibel, wäre es heute wieder tot.

Sehe ich teilweise auch so. Trotzdem gibt es auf Linux bzw. im GCC Modus zum Beispiel volle C++14 Kompatibilität und im Microsoft Modus gibt es das nicht. Als "Kompatiblität" zu MS. :roll:
Aber zum Teil Bugs und Ineffiziente ABIs nachgebaut. Zum Beispiel im Name Mangling. Wie ich zuletzt geschaut habe, habe ich keine Möglichkeit gefunden, LLVM/Clang als Plattform einzusetzen und nicht bloß LLVM/Clang als billigen Nachbau des Microsoft-Compilers zu nutzen. Es gibt keine Möglichkeiten zu geben, viele dieser Dinge abzuschalten, wie es mit allen GCC Extensions der Fall ist. Außerdem würde ich gerne Libc++ nutzen. Das schien auch nicht möglich zu sein.

Vielleicht sollte ich aber auch einfach nochmal einen Anlauf versuchen. Meine Erfahrung ist bestimmt schon wieder ein Jahr alt und angeblich scheint sich zum Beispiel aktuell ja etwas mit dem Exception Support auf Windows etwas zu tun.

[Krishty]

Ja, aber das funktioniert nicht mit statischen Daten. Wenn du dir z.B. eine Bitmaske für abs() baust, sorgt _mm_set_ps() in Visual C++ für eine dynamische Initialisierungsfunktion statt eines einfachen Dateneintrags. *spuck*

In Clang ist das aber anders. Wenn du es also mit Intrinsics machst, hast du 100% der Effizienz in Clang und bist trotzdem wenigstens noch zu Visual Studio kompatibel.

Ja toll, aber im Augenblick bin ich in Clang nicht einmal 50 % effizient ;) Bis ich den als Haupt-Compiler nutzen kann dauert es – die bisherige Entwicklung extrapoliert – noch bis 2016 oder 2017 :(

Aber zum Teil Bugs und Ineffiziente ABIs nachgebaut. Zum Beispiel im Name Mangling.

Und die Alternative? Sollen die Compiler-Entwickler jede Lib der Welt mit korrektem Name Mangling neukompilieren? Jedes Windows SDK nachträglich ändern, damit Clang-Nutzer endlich mal eine Windows-Exe kompilieren können? Name Mangling und ABI ist ein denkbar schlechtes Beispiel. Denn die sind nunmal da, auf allen Rechnern ausgeliefert, und kein Compiler der Welt wird die je wieder ändern können. Ganz ab davon sind sie Implementation Detail.

Dass Visual C++ nicht standardkonform ist, hatte nicht die Absicht, dass man keinen Standard-C++-Code mehr auf ihm kompilieren können soll. Das geht nämlich bis vor C++'11 erstaunlich gut. Es ging eher darum, ein paar Nonsens-Fälle, wie

• überflüssiges typename vor abhängigen Typen
• Foo<X<int> > statt Foo<X<int>>
• nichtkonstante Referenz als Parameter
• erst später deklarierte nicht-abhängige Typen in Templates

kompilieren zu lassen, obwohl der Standard es verboten hätte, um den Compiler einfacher benutzbar zu machen (exakt das Gegenteil von GCCs Sprachpedanterie). Die Absicht war wirtschaftlich – dass Leute, die einmal Visual C++ benutzen, nie mehr zurückwechseln können, weil sie sich dann mit dieser Krätze herumnerven müssten. Tatsächlich haben es viele dieser "Erweiterungen" auch in neue C++-Standards geschafft (und hätten das nie ohne Visual C++). Bei der meisten Kompatibilitätsarbeit an Clang geht es um solche Dinge, und nicht um wirklich kaputte Sachen und Bugs.

Dass Visual C++ hoffnungslos unterbesetzt ist um neue Standards und die STL-Wucherungen komplett zu implementieren, ist schade. Aber Clangs Kompatibilitätsarbeit spart den Entwicklern weltweit im Wortsinn Millionen Arbeitsstunden. Standardkonformer bedeutet nicht besser. Wenn man sowas annimmt, kommt am Ende GCC heraus.

Wie ich zuletzt geschaut habe, habe ich keine Möglichkeit gefunden, LLVM/Clang als Plattform einzusetzen und nicht bloß LLVM/Clang als billigen Nachbau des Microsoft-Compilers zu nutzen. Es gibt keine Möglichkeiten zu geben, viele dieser Dinge abzuschalten, wie es mit allen GCC Extensions der Fall ist. Außerdem würde ich gerne Libc++ nutzen. Das schien auch nicht möglich zu sein.

Das gilt für Clang für Visual Studio. Clang für Windows arbeitet AFAIK ganz normal ohne Microsoft-Erweiterungen mit libc++. Vorkompilierte Dateien sind leider schwer zu finden (siehe wieder Eintrittsbarrieren), aber es gibt offizielle Dokumentation, wie man Clang unter Windows mit (nicht für!) Visual C++ baut.

Vielleicht sollte ich aber auch einfach nochmal einen Anlauf versuchen. Meine Erfahrung ist bestimmt schon wieder ein Jahr alt und angeblich scheint sich zum Beispiel aktuell ja etwas mit dem Exception Support auf Windows etwas zu tun.

Visual-C++-kompatibel existiert der immernoch nicht. Dass ich jetzt kompilieren kann liegt vor allem daran, dass ich in letzter Zeit alle Exceptions rausgenommen habe.

[Spiele Programmierer]

Und die Alternative? Sollen die Compiler-Entwickler jede Lib der Welt mit korrektem Name Mangling neukompilieren?

Nö, aber die meisten Libs müsste man ja gar nicht Neukompilieren. Die Libs die ich so verwende, sind zum einen zu 80% C Libs oder besitzen mit 90% wenigstens eine C API, oder sind Open Source oder Header only. Inzwischen füge ich eh alle Libs direkt mit Sourcen ins Projekt ein, um genau solche Probleme zu vermeiden. Das gibt es ja auch ganz ohne Clang zwischen jeder Visual Studio Version und ist eigentlich nichts Neues. Also selbst wenn man es nicht so einfach hätte - mit Visual Studio hat man ja den selben Ärger alle 1-2 Jahre. Ist ja nicht so, dass die Binärkompatibel wären. Nein, aber Clang muss es sein. Für geringen bis keinen Gewinn und gewissen Verlusten, für mich persönlich zumindest.

nichtkonstante Referenz als Parameter

Für Funktionen? Das ist doch keine MS Extension.

Standardkonformer bedeutet nicht besser.

Nicht zwingend, aber in dem Fall ist es ein Vorteil, weitere Features zur Verfügung zu haben. An "constexpr" wäre ich, nur als Beispiel, sehr stark interessiert gewesen und das gab es deswegen nicht richtig. Nicht mal die hässliche Variante aus C++11 hat funktioniert, glaube ich. Und, ich will ja gerade Clang verwenden um diese Features zu bekommen. Wenn der einzige "Vorteil" darin liegt, das Debugging nicht mehr funktioniert und ich eine ganze Menge Arbeit habe, aber sonst alle für mich interessanten Features deaktiviert sind, dann bringt mir das nix. Auch nicht; wenn es kompatibel wäre. Es ist ein Nachbau, keine Verbesserung. Für mich zumindest. Ich weiß nicht, was dich genau für den Umstieg motiviert, aber für mich sind die verbleibenden tatsächlichen Vorteile nicht entscheidend.

Das gilt für Clang für Visual Studio. Clang für Windows arbeitet AFAIK ganz normal ohne Microsoft-Erweiterungen mit libc++. Vorkompilierte Dateien sind leider schwer zu finden (siehe wieder Eintrittsbarrieren), aber es gibt offizielle Dokumentation, wie man Clang unter Windows mit (nicht für!) Visual C++ baut.

Ja das habe ich sogar schonmal gemacht. War weniger schwierig als ich befürchtet hätte, aber es fehlt eine Implementierung der C Stdlib und Libc++ war noch nicht bereit für Windows.

[Krishty]

nichtkonstante Referenz als Parameter

Für Funktionen? Das ist doch keine MS Extension.

Brainfart. Non-constant reference to temporary meinte ich. Hach ist das ein schön einfacher Name :D

[Krishty]

Und die Alternative? Sollen die Compiler-Entwickler jede Lib der Welt mit korrektem Name Mangling neukompilieren?

Nö, aber die meisten Libs müsste man ja gar nicht Neukompilieren. Die Libs die ich so verwende, sind zum einen zu 80% C Libs oder besitzen mit 90% wenigstens eine C API, oder sind Open Source oder Header only.

Und sind 10–20 % aller Bibliotheken der Welt eine Inkompatibilität, die kein Problem darstellt? ;) Viele Firmen haben nicht einmal mehr den Quelltext zu einigen ihrer Libs, oder benutzen eine spezielle Version von vor acht Jahren, die man nirgends mehr kriegt. Viele Firmen rühren die aktuelle Visual Studio-Version nicht an. Herrgott, ich kenne Läden, wo Module noch mit Visual C++ 6 kompiliert werden. Clang ist der Neuankömmling. Wenn er sich da profilieren will, muss er erstmal Scheiße fressen. Wenn Clang die Führung übernommen hat, können sie es ja ändern. Dann sind alle gezwungen, ihre Libs zu aktualisieren (unwahrscheinlich). Oder wieder zu Visual Studio zurückzuwechseln (wahrscheinlicher).

An "constexpr" wäre ich, nur als Beispiel, sehr stark interessiert gewesen und das gab es deswegen nicht richtig. […] Es ist ein Nachbau, keine Verbesserung. Für mich zumindest. Ich weiß nicht, was dich genau für den Umstieg motiviert, aber für mich sind die verbleibenden tatsächlichen Vorteile nicht entscheidend.

Dann benutz halt nicht Clang für VS, sondern das rohe Clang. Aber dann musst du eben auch zu libc++ wechseln, hunderttausend Fehler beheben bevor du wieder kompilieren kannst, alle Microsoft-Libs wegschmeißen und danach zwei Wochen debuggen, statt das alles schrittweise auf die nächsten Jahre zu verteilen. Oder eben nicht, wenn du die ganze Zeit standardkonform programmiert hast. Engineering is about tradeoffs.

[Spiele Programmierer]

Du beschreibst ja ganz schön, dass es eben so ist wie es ist, nur genau das ist eben mein "Jammerfaktor", den ich bei der Sache habe.
Sollen die Firmen halt nicht ihren Quellcode verschmeißen. ;)

Ich wünschte halt, Clang wäre etwas freundlicher zu der anderen Nutzergruppe. Die die nicht mit Visual Studio 6 arbeitet sondern lieber einfach gerne C++14 und nicht die Extrawürste von Microsoft hätten.

[Krishty]

Boah wo wir gerade bei Ärgernissen waren: Warum darf goto nicht über Variableninitialisierungen springen?!

  goto foo; // warning : jump from this goto statement to its label is a Microsoft extension
  int i = 3; // note: jump bypasses variable initialization
  foo:
  return;

Fix:

  goto foo;
  int i;
  i = 3;
  foo:
  return;

WOLLT IHR MICH VERARSCHEN?! Wer denkt sich so einen Müll aus? Waren da wieder analfixierte RAII-Fanatiker am Standard?

[Krishty]

Soweit ich weiß ist es in der Tat so, dass LLVM/Clang immer den Plattform spezifischen Linker verwendet. Es gibt einen Linker im LLVM Projekt, LLD. Der funktioniert angeblich sogar auch unter Windows, hat aber scheinbar generell noch keine Unterstützung für Debugginginformationen jedweder Art.

Danke für die Information, damit habe ich nun zumindest schonmal ein Hello World ganz ohne Visual Studio kompiliert und gelinkt gekriegt :) Es war 1 KiB groß. Bis ich die Visual-C++-CRT eingebunden habe :roll:

Nachtrag: Jetzt habe ich auch was kompiliert bekommen, das die Visual C++-CRT benutzt. Ich musste allerdings von Hand ___xi_a, ___xi_z, ___xc_a, und ___xc_z deklarieren. Ja toll, statische Initialisierung funktioniert nicht -.- Wat do?

Und kann mir jemand mit mehr Unix-Erfahrung sagen, was hat es mit ___main auf sich hat?

[Biolunar]

Und kann mir jemand mit mehr Unix-Erfahrung sagen, was hat es mit ___main auf sich hat?

___main sagt mir nichts. Der Linker ld erwartet standardmäßig _start als Einstiegspunkt der CRT, vielleicht ist ___main das Windows-Gegenstück?

[Krishty]

Das Komische ist, dass er sowohl _mainCRTStartup (welches main() aufruft) als auch ___main erwartet und scheinbar beide *hintereinander* ausgeführt werden ó_Ô

Auf der Suche nach meinen globalen Konstruktoren habe ich mir das Assembly angeschaut. Dort werden alle globalen Konstruktoren von einer Funktion __GLOBAL__sub_I_main.cpp aufgerufen, die jedoch ihrerseits von nirgends aufgerufen wird. Da der Name nicht fest ist, sondern vom Namen der cpp abhängt (und jedes Modul seine eigene hat), kann ich die auch schlecht manuell aufrufen. Im Augenblick ist das für mich noch sehr mysteriös.

[dawit]

Wenn ich das richtig verstanden habe, will Microsoft das Clang-Frontend mit ihrem eigenen Backend verbinden: http://blogs.msdn.com/b/vcblog/archive/ ... ndows.aspx.
Damit hätte man dann wohl alle Vorteile von Clang (C++14, Fehlermeldungen) auch unter Windows.

[Jonathan]

Hm, ich bin in Compilerinterna nur mäßig bewandert, kann mal einer erklären wie das zu den Bemühungen des Clang Teams, Clang VC kompatibel zu machen, steht? Denn das scheint ja auch schon recht weit zu sein, für mich hört es sich ein wenig so an, als würde MS die Kompatibilität jetzt auf einem anderen Wege sicherstellen wollen, wodurch man zwei verschiedene Wege für das selbe Ziel hätte, was wiederum entweder zu fehlerträchtigen Doppelstandards, oder zur Unbedeutsamkeit eines der beiden Projekte (was schade um die Arbeit wäre) führen muss...