# Update von clang-10 "out of memory"

## alexander_ro

Hi Mädels ... Jungs ...  :Smile: 

Beim üblichen Gentoo Updaten bekomme ich bei der neuen clang Version eine Fehlermeldung. Im Syslog steht dann folgendes:

```

ul  4 19:04:39 alien kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,task=ld,pid=26791,uid=250

Jul  4 19:04:39 alien kernel: Out of memory: Killed process 26791 (ld) total-vm:7938052kB, anon-rss:2600640kB, file-rss:1712kB, shmem-rss:0kB, UID:250 pgtables:15568kB oom_score_adj:0

Jul  4 19:04:39 alien kernel: oom_reaper: reaped process 26791 (ld), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

```

Der Rechner hat 8GB RAM und ein bisschen SWAP ... den -j Parameter habe ich schon reduziert das hatte keinerlei Auswirkung auf den Speicherbedarf.

Kann es sein das clang ein bisschen Kaputt ist? ... ich bin mir nicht sicher.

Grüße

Alexander

----------

## franzf

Das Problem ist nicht das KOMPILIEREN der sourcedateien (worauf MAKEOPTS einen Einfluss hat) sondern das LINKEN (Prozess "ld").

Beim Linken müssen die Symbole sämtlicher object files in eine Datei gepackt werden, was viel Speicher verbraucht.

Der ld.bfd - default in binutils - braucht leider besonders viel.

Lösung: Wechsel mal auf den gold linker:

https://wiki.gentoo.org/wiki/Gold

----------

## alexander_ro

Ja schon  der Linker ist mir aufgefallen ich war mir nur nicht sicher ob der die Option auch verwendet.

Stimmt schon man braucht alle Symbole die in dem fertigen Programm enthalten sind. Man muss aber nicht alles zu einem Riesigen Monolithen zusammen linken ...  :Sad: 

Fromme Sprüche:

```

Clang is probably a great solution for you.

```

für mich ist das nicht wahr kann man ja nicht mal übersetzen.

Der Mist wurde mal mit firefox glauche ich als Abhängigkeit installiert und Frist Ressourcen ohne Ende. Weil er recht oft neu gebaut werden muss. Scheinbar ändert sich an dem viel hat er aber auch dringend nötig wenn man den mit 8GB RAM nicht Compilieren kann das Design von dem muss ja ziemlich kaputt sein.

Ich werde man wieder versuchen den los zu werden. Der ist glaube ich irgendwann als Abhängigkeit zu Firefox und Thunderbird installiert worden. Es hieß er wäre zwingend dafür nötig. Wenn das so ist werde ich mal suchen und die beiden gleich mit ersetzen.

----------

## franzf

 *alexander_ro wrote:*   

> Der Mist wurde mal mit firefox glauche ich als Abhängigkeit installiert und Frist Ressourcen ohne Ende. Weil er recht oft neu gebaut werden muss. Scheinbar ändert sich an dem viel hat er aber auch dringend nötig wenn man den mit 8GB RAM nicht Compilieren kann das Design von dem muss ja ziemlich kaputt sein.

 

clang ist ein moderner Compiler, Design ist top. Was Mist ist, das ist der ld.bfd, also der default linker. Das ist bekannt, nicht nur clang hat mit dem Probleme, sondern oft auch webkit, chromium, etc. Halt alles was heutzutage so an größeren Frameworks produziert wird.

Lösung habe ich schon erwähnt, aber hier nochmal: Ersetze den Linker! Nimm ld.gold statt ld.bfd. Punkt. Link zum Gentoo Wiki findest du im vorherigen Post.

 *Quote:*   

> Ich werde man wieder versuchen den los zu werden. Der ist glaube ich irgendwann als Abhängigkeit zu Firefox und Thunderbird installiert worden. Es hieß er wäre zwingend dafür nötig. Wenn das so ist werde ich mal suchen und die beiden gleich mit ersetzen.

 

Wenn dich Kompilieren so stört dann nimm doch einfach firefox-bin und thunderbird-bin. Oder (so wie ich) eine binary-Distribution ala arch, suse, fedora...

----------

## alexander_ro

Na ja also erstens steht da oben das mich das andauernde neu bauen von clang und llvm stört und nicht das von firefox und thunderbird. Die bauen erheblich seltener neu.

Alles was man zu einem Monolithen zusammen linkt das man es nicht mehr in 8GB Speicher bekommt ist Schrott Design. Modern ist nicht unbedingt gleich besser. Vermutlich stecken Facebook oder Google dahinter und haben vergessen das nicht jeder über mehrere Milliarden teure Rechenzentren verfügt.

Der ld kann Problemlos Thunderbird und Firefox auf meinem Rechner linken das ist überhaupt kein Problem.

Die Frage ist halt was Handel ich mir mit dem anderen Linker für Probleme ein. Ist vermutlich nicht ohne Grund das er nicht default ist.

----------

## franzf

 *alexander_ro wrote:*   

> Na ja also erstens steht da oben das mich das andauernde neu bauen von clang und llvm stört und nicht das von firefox und thunderbird. Die bauen erheblich seltener neu.

 

Aber firefox hat clang fix in den Abhängigkeiten, deshalb als Lösung -> firefox-bin + thunderbird-bin.

 *Quote:*   

> Alles was man zu einem Monolithen zusammen linkt das man es nicht mehr in 8GB Speicher bekommt ist Schrott Design. Modern ist nicht unbedingt gleich besser. Vermutlich stecken Facebook oder Google dahinter und haben vergessen das nicht jeder über mehrere Milliarden teure Rechenzentren verfügt.

 

Deine laienhafte Meinung oder fundierte Kenntnis nach jahrelanger Berufserfahrung?

Wenn du da weiter diskutieren willst, wäre auch ein vollständiges build.log nicht schlecht, dass man sieht was da gerade gelinkt wurde.

BTW.: Bist du dir sicher, dass nicht irgendein anderer Prozess zu dem Zeitpunkt gewaltig Speicher gebraucht hat? Z.B. ein firefox mit 100 tabs oder ein gigantisches Postfach in Thunderbird?

 *Quote:*   

> Die Frage ist halt was Handel ich mir mit dem anderen Linker für Probleme ein. Ist vermutlich nicht ohne Grund das er nicht default ist.

 

https://bugs.gentoo.org/269315

Die üblichen Fehler sind dem korrekteren Verhalten geschuldet. Aber z.B. grub2 scheint gar nicht zu starten.

Schau hier für selektives Setzen eines linkers:

https://forums.gentoo.org/viewtopic-p-7938204.html#7938204

Letzte Zeile, die bfd.conf. Kannst du auch so hindrehen, dass du das nur für clang auf gold setzt und dein System weiterhin bfd verwendet.

Ich hatte jahrelang das System nur mit gold gebaut und nie wirkliche Probleme.

----------

## Josef.95

Hm, vom global auf den gold Linker umstellen bin ich wieder ab -- es gibt leider einige Pakete im tree die damit nicht klarkommen, und übel auf die Nase fallen (lange Zeit war es auch nicht möglich einen Linux Kernel mit gold Linker zu bauen) :-/

 *alexander_ro wrote:*   

> Der Rechner hat 8GB RAM und ein bisschen SWAP ... den -j Parameter habe ich schon reduziert

 

Was heißt "reduziert"? Von was auf was?

Ich denke wenn der RAM nicht anderweitig belegt ist, dann sollte -j4 mit 8 GB RAM funktionieren. Wenn der RAM noch mit anderen Kram genutzt wird, dann eher noch weiter runtergehen.

/edit: btw, toller Artikel zum thema swap :) --> https://chrisdown.name/2018/01/02/in-defence-of-swap.html

----------

## franzf

 *Josef.95 wrote:*   

> Hm, vom global auf den gold Linker umstellen bin ich wieder ab -- es gibt leider einige Pakete im tree die damit nicht klarkommen, und übel auf die Nase fallen (lange Zeit war es auch nicht möglich einen Linux Kernel mit gold Linker zu bauen) :-/

 

Hattest du tatsächlich Laufzeitfehler? Oder war es das übliche default-linken von lm, lpthread usw?

----------

## alexander_ro

 *Quote:*   

> Deine laienhafte Meinung oder fundierte Kenntnis nach jahrelanger Berufserfahrung?

 

Erkläre mir doch mal was an dem zusammen linken von Monolithen so tolles Software Design sein soll?

Schade wenn es der Firefox nur mit clang kann ich dachte mit dem USE-Flag clang kann man das evtl. ändern.

Vielleicht wird es doch langsam Zeit Firefox und Co. vom Rechner zu werfen und alternativen zu suchen. Richtig begeistert war ich seit die auf Google Software umgestellt haben so nicht mehr von dem Ding.

Von den 8GB sind noch 6GB und fast alles von den 10GB SWAP frei. Klar läuft da noch der Rest vom Betriebssystem den xfce zähle ich zum Betriebssystem.

Er sagt im Log: free swap: 0KB, Total swap = 10485756kB deshalb hat er dann den Prozess beendet.

Mit dem Rechner wurde zu dem Zeitpunkt nicht gearbeitet. Nur clang gebaut ...

@Josef.95

Reduziert von -j8 auf -j4. Mit -j8 hat sich bis vor kurzem das clang Ding noch bauen lassen.

Ja interessant das mit dem SWAP. Aber irgendwie finde ich schon das SWAP Notfall Speicher ist aber halt nicht nur. Mein Rechner hat im Normalbetrieb bei mir 3-4 GB freien RAM ganz ehrlich da ist es völlig egal ob ein bisschen Speicher von Uralten Speicherseiten belegt wird oder nicht. Ein bisschen SWAP benutzt der aber immer egal wie viel Speicher frei ist. SWAP wird Hauptsächlich für den shutdown to disk benutzt auf dem Rechner.

----------

## Josef.95

 *franzf wrote:*   

>  *Josef.95 wrote:*   Hm, vom global auf den gold Linker umstellen bin ich wieder ab -- es gibt leider einige Pakete im tree die damit nicht klarkommen, und übel auf die Nase fallen (lange Zeit war es auch nicht möglich einen Linux Kernel mit gold Linker zu bauen) :-/ 
> 
> Hattest du tatsächlich Laufzeitfehler? Oder war es das übliche default-linken von lm, lpthread usw?

 

Nein, Laufzeitfehler habe ich keine bemerkt, es waren eher die üblichen Abbrüche beim bauen/linken. Ich muss aber gestehen das meine letzten Tests Jahre her sind -- habs ehrlich gesagt lange nicht mehr getestet.

----------

## Josef.95

@alexander_ro

Hm, und portage baute zu der Zeit auch wirklich nur dieses eine clang Paket? Sprich die emerge --jobs Option wurde nicht genutzt, und Späße wie PORTAGE_TMPDIR im tmpfs ist auch nicht eingebunden?

Vorschlag: Teste den build bitte mal mit MAKEOPTS="-j2"

Wenn das auch fehlschlägt, dann poste bitte mal das komplette build.log und die dazugehörige emerge --info

und die Ausgabe von 

```
df -h `portageq envvar PORTAGE_TMPDIR`/portage
```

----------

## mike155

 *franzf wrote:*   

> Lösung: Wechsel mal auf den gold linker:

 

Nach diesem Artikel hatte ich eher den Eindruck, dass gold tot ist...

----------

## mike155

 *alexander_ro wrote:*   

> Reduziert von -j8 auf -j4.

 

Für große in C++ geschriebene Pakete sollte man mittlerweile mit 2 GB RAM pro Job rechnen. Swap hilft nicht! Hinzu kommt, dass man noch weiteres RAM braucht für Betriebssystem und /var/tmp/portage, falls /var/tmp/portage ein tmpfs ist.

Es wundert mich also nicht, dass es bei "-j4" und "-j8" Probleme gibt.

@Josef.95 hat Recht: probiere es mal mit "-j2".

----------

## alexander_ro

Mich wundert das schon weil es wie gesagt bisher mit -j8 Problemlos lief ...

Ich kenne auch sonst keine Software die für einen Compilejob 2GB braucht. Weil ich dann auch keinerlei Software auf einem Raspi für Gentoo bauen könnte. Der baut alles mit -j2 und einem GB. Der gcc und anderes was da so läuft ist auch nicht gerade ein mini Projekt.

Wenn SWAP nichts bringt wieso waren dann 10GB SWAP voll?

Mit dem Auslagern der 2GB belegtem RAM wohl eher nicht da ist noch eine Lücke mit Lumpigen 8GB ...

Ich probiere mal mit -j2 aber das dauert bis es fertig ist.

@Josef.95

Ich habe da nichts das mit --jobs oder tmpfs zu tun hätte.

----------

## mike155

 *alexander_ro wrote:*   

> Wenn SWAP nichts bringt wieso waren dann 10GB SWAP voll?
> 
> Mit dem Auslagern der 2GB belegtem RAM wohl eher nicht da ist noch eine Lücke mit Lumpigen 8GB ...

 

Es gibt Speicherbereiche, die "non-swapable" sind. Von daher kann es gut sein, dass man einen OOM Fehler bekommt, obwohl von den 10 GB Swap Space erst 2 GB belegt sind.

Swap hilft, wenn man lang laufende Prozesse hat, die viel Hauptspeicher benötigen - die aber auf einzelne Speicherbereiche nur sehr selten zugreifen. Diese selten genutzten Speicherbereiche können dann tatsächlich auf die Festplatte ausgelagert werden - und dann kann Swap tatsächlich etwas bringen.

Dieses Szenario hat man aber nicht bei emerge. Hier werden kurz hintereinander Tools der Build-Chain aufgerufen, die bei großen C++ Programmen viel Hauptspeicher brauchen und auch damit arbeiten. Wenn hier Teile des Hauptspeichers auf die Festplatte ausgelagert werden, führt dies zu sehr viel I/O, weil nach kürzester Zeit doch wieder auf den ausgelagerten Speicher zugegriffen werden muss. Dann müssen die Daten wieder eingelesen werden - und zuvor müssen andere Daten ausgelagert werden, die dann aber auch nach kürzester Zeit wieder benötigt werden.

Bei dem Szenario "emerge" kann man den Hauptspeicher mit Swap vielleicht um 10% oder 20% vergrößern (virtuell). Aber man kommt nicht von 8 GB auf 18 GB.

 *Quote:*   

> Ich kenne auch sonst keine Software, die für einen Compilejob 2GB braucht. Weil ich dann auch keinerlei Software auf einem Raspi für Gentoo bauen könnte. 

 

Schon mal Webkit, Webengine & friends auf dem Raspberry mit "-j4" gebaut?   :Wink: 

----------

## Tyrus

Hm - also ich hab mit clang bisher keine Probleme an die mich mich erinnern würde.

Hab hier jetzt auch nicht mehr als 8GB Speicher. Arbeite mit "-j3". System ist: Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz (das sind 2 Prozessoren)

Swap hab ich großzügig eingeräumt mit 16 GB. Wobei kaum der Fall eintritt das mehr als 2 GB genutzt werden. Aber dann ist die Last am System auch hoch. 

Dazu läuft kde als Oberfläche wenn das gebaut wird.

Aktuell sind sogar zwei Versionen von clang installiert. Noch nicht alles ist auf clang:10 umgestellt:

```

Calculating dependencies... done!

  sys-devel/clang-9.0.1 pulled in by:

    app-doc/doxygen-1.8.17 requires <sys-devel/clang-10:9/9=

    dev-qt/qdoc-5.15.0 requires sys-devel/clang:9/9=

    dev-qt/qt-creator-4.12.3 requires <sys-devel/clang-11:9/9=

    dev-util/kdevelop-5.5.2 requires >=sys-devel/clang-6.0:9/9=

```

Und ja ich hab auch den Gold-Linker im Einsatz. Noch keine Probleme deswegen bekommen.

Ein genlop zeigt:

```

[...]

     Fri May 29 13:52:49 2020 >>> sys-devel/clang-9.0.1

       merge time: 1 hour, 48 minutes and 26 seconds.

     Tue Jun 30 18:23:40 2020 >>> sys-devel/clang-10.0.0

       merge time: 2 hours, 28 minutes and 40 seconds.

   Total builds: 30

   Global build time: 1 day, 17 hours, 48 minutes and 7 seconds.

   Average merge time: 1 hour, 23 minutes and 36 seconds.

   Info about currently installed ebuild:

   * sys-devel/clang-9.0.1

   Install date: Fri May 29 13:52:49 2020

   USE=""

   CFLAGS="-march=native -O2 -pipe"   CXXFLAGS="-march=native -O2 -pipe"   LDFLAGS="-Wl,-O1 -Wl,--as-needed"

   * sys-devel/clang-10.0.0

   Install date: Tue Jun 30 18:23:40 2020

   USE=""

   CFLAGS="-march=native -O2 -pipe"   CXXFLAGS="-march=native -O2 -pipe"   LDFLAGS="-Wl,-O1 -Wl,--as-needed"

```

So  oft musste das jetzt nicht neu gebaut werden. Komme auf 30 Builds seit März 2015. Damals wars aber noch clang-3.5.0 ...

----------

## alexander_ro

zu 1) Ja gibt es aber dann erklär mir doch bitte warum im Log steht "free SWAP 0KB" wenn er die Sachen nicht auslagern darf?

zu 2) Das ist nur fast richtig dem Kernel ist es egal wie schnell Seiten getauscht werden müssen. Der macht das in der Hoffnung so alles am leben zu erhalten. Erst wenn er SWAP=0KB hat killt er Prozesse. Die nicht auslagerbaren Bereiche gibt es eigentlich nur für den Kernel selbst und Hardware nahe Speicherbereiche die nicht unter alleiniger Kontrolle des Kerns stehen. gcc und wie hier der ld haben so etwas sicher nicht.

zu3) siehe 1 und 2

Der llvm wurde auf dem Raspi gebaut bis mir aufgefallen ist das ich den gar nicht brauche. Ob da clang auch dabei war kann ich mich nicht mehr erinnern aber vermutlich schon weil man ja sonst mit dem llvm nichts anfangen kann. Das letzte mal ist jetzt vielleicht 1 Jahr her. Da ging das noch.

Software die sich mit 16 GB Speicher (6 RAM, 10 SWAP) nicht bauen lässt ist hochgradig kaputt. Das hat nichts mit C++ oder dem ld zu tun sondern mit extrem schlechtem Design. Ich habe keine Ahnung wer hinter clang und llvm steckt das ist ja auch nur eines der weiteren Kommerziellen Projekte die für lau Massen an Menschen für sich schuften lassen. Um dann die daraus entstehenden Produkte für Unsummen genau an diese Menschen zu verkaufen. OpenSource ist heute ja mehr Kommerz als der Kommerz selber.

@Tyrus

Du hast auch die Version die ich habe und die auf dem System gebaut wurde. Die neue ist jetzt kaputt weil man die nicht mehr bauen kann. Das mit dem Gold Linker mache ich nicht. Ich habe viele System mit Gentoo laufen und werde nicht anfangen jedem Programm seine Lieblings Build Umgebung bauen. Was mit dem Standard nicht läuft ist kaputt. Wenn die Mozies glauben eine Hersteller Abhängikeit in einem wie sie immer betonen freiem OpenSource Projekt sei eine gute Sache wird es so Zeit Mozilla vom Rechner zu werfen. Ich verlasse mich mal darauf das die Macher der binutils wissen warum der Oberflächlich besser aussehende Linker nicht default ist.

Vorher probiere ich aber noch was dieses USE-Flag clang beim Firefox macht.  

Wozu ein USE Flag wenn clang Zwang ist?

----------

## alexander_ro

Das ist jetzt interessant:

```

alien /home/alex # equery uses firefox

[ Legend : U - final flag setting for installation]

[        : I - package is installed with flag     ]

[ Colors : set, unset                             ]

 * Found these USE flags for www-client/firefox-68.9.0:

 U I

 - - clang                : Use Clang compiler instead of GCC

```

Das USE-Flag clang ist nicht gesetzt aber er will trotzdem clang und llvm wieder installieren. Irgendwie kommt mir das so vor wie wenn es auch nicht ganz richtig wäre.

----------

## franzf

 *alexander_ro wrote:*   

> Das ist jetzt interessant:
> 
> ```
> 
> alien /home/alex # equery uses firefox
> ...

 

Schau doch einfach ins ebuild, dann wird klar was USE=clang macht.

Und dein Design-Genörgel nervt. Was den ld.bfd aus der Bahn wirft ist höchstwahrcheinlich template-code. Zig Instantiierungen für verschiedene Typen, irgendwelche verschachtelten Compilezeit-Algorithmen können schon einiges an Symbolen erzeugen. Wenn da aus mehreren Übersetzungseinheiten solche Wuste zusammenkommen hast du ein Problem, wenn der Linker Speicher verschwendet.

 *Quote:*   

> Der llvm wurde auf dem Raspi gebaut bis mir aufgefallen ist das ich den gar nicht brauche. Ob da clang auch dabei war kann ich mich nicht mehr erinnern aber vermutlich schon weil man ja sonst mit dem llvm nichts anfangen kann.

 

Bitte auch mal schauen, was genau llvm und clang sind. llvm geht nämlich sehrwohl ohne clang. llvm als lib wird u.A. auch von mesa verwendet.

----------

## mike155

 *Josef.95 wrote:*   

> /edit: btw, toller Artikel zum thema swap  --> https://chrisdown.name/2018/01/02/in-defence-of-swap.html

 

Schon klar, dass die Fans des Swap-Subsystems ihr System verteidigen   :Smile: 

Vermutlich muss man etwas unterscheiden. Bei Embedded Systemen oder anderen Maschinen mit wenig RAM - oder bei ganz speziellen Anforderungen - kann Swap tatsächlich sinnvoll sein.

Bei Desktop-Rechnern und Servern benutze ich seit 10 Jahren kein Swap mehr. Bei Servern schalte ich zudem nach Möglichkeit Memory Over-Commitment aus. Dann stört auch der OOM Killer nicht mehr. In Zeiten, in denen RAM so preiswert ist, kauft man halt ein paar GB RAM zusätzlich. Dafür kann man Swapping und Memory Over-Commitment ausschalten. 

Das ist doch ein guter Deal! Nie wieder hängende Systeme, die unter exzessivem Swapping leiden. Nie wieder vom OOM Killer abgeschossene Prozesse! Und über Dienste wie earlyoom muss man sich auch nicht mehr wundern.  :Smile: Last edited by mike155 on Sun Jul 05, 2020 7:49 pm; edited 2 times in total

----------

## alexander_ro

@franzel

Ich schau auf den Text und das macht es nicht also ist mindestens der Text falsch ... naja vielleicht ist auch meine Übersetzung des Textes falsch. Nicht meine Schuld das es keinen Deutschen gibt.

Ja danke Du nervst auch ...  :Sad: 

Spar Dir in Zukunft so blöde Kommentare kann ich gut darauf verzichten. Wenn die ihre Instanzenbildung in den Templates nicht im griff haben ist das auch nicht mein Problem ich habe den Mist nicht Programmiert. Das Design ist Schrottreif ob Dir das passt geht mir am Arsch vorbei.

Ich weiß nicht genau was llvm und clang sind was mir auch wurscht ist es muss funktionieren sonst fliegt es raus. Ich brauch den Mist nicht und bekomme es nur als irgendwelche Abhängigkeiten aufgezwungen und verbringe Tage mit der Fehlersuche und Beseitigung. Was ich aber genau weiß ist das der Schrott sein langem nur Probleme Verursacht.

Also entweder sagst Du was Sache ist oder behalte Deine Kommentare für Dich ... ja Danke.

----------

## alexander_ro

 *Quote:*   

> 
> 
> ... kauft man halt ein paar GB RAM zusätzlich ...
> 
> 

 

Ja habe ich ja gemacht. Belegt sind bei mir meist nur 2-3 GB speicher. Habe also schon 5 zusätzlich gekauft.

Als extra wegen "shutdown to disk" habe ich noch 10GB als SWAP. Die reichten aber nicht der Kernel sagte 0KB SWAP verfügbar. Also ein paar GB mehr kaufen löst das Problem nicht. Wenn ich noch Platz hätte würde ich einfach mal SWAP größer machen und schauen wie viele GB der noch verbrät. Aber das ist den Aufwand nicht Wert für so eine Software. Ich habe nun llvm und clang entfernt und schau mal was wegen wegen Tyrannei auf clang nicht mehr funktioniert fliegt auch gleich mit raus. Ich brauch Software die Funktioniert.

----------

## Josef.95

@alexander_ro,

uff, nun bleib mal bitte aufm Teppich. Ja dein Design-Genörgel nervt mich auch, und es hilft auch niemanden weiter.

Franz hat doch mit guten Erklärungen versucht zu helfen. Wenn du diese Hilfe nicht annehmen magst, dann ist das eher traurig, und kein Grund ihn dafür auch noch anzupamppen.

----------

## alexander_ro

@Josef.95

Ich muss mir keine Beleidigungen gefallen lassen nur weil ihn meine Meinung echauffiert. Also er hat mich angepamppt. Gut ich habe zurückgepamppt. Klar das die Forumsurgesteine zusammenhalten aber das kommt jetzt schon Arg unfair. Wem es nicht gefällt der muss es ja nicht lesen oder antworten. Ich bekomme hier so nur recht selten eine Antwort auf Fragen (außer die letzten zwei) aber wenn es dann nur wegen seichter Kritik an einem unbegrenztem Speicherverbrauch ausartet dann ist es besser man bekommt keine Antwort.

Hilfe ähm wo denn bitte ...

Ich weiß selbst wie man eine Memory Overflow mit kaputten Template Code in C++ generiert. Ich Programmiere sei Jahrzehnten in C++.

----------

## mike155

@alexander_ro: im englischsprachigen Teil der Gentoo Foren wird häufiger von OOM Killer Problemen berichtet. Fast immer im Zusammenhang mit den großen in C++ geschriebenen Paketen.

Manchmal posten die Betroffenen direkt die OOM Killer Nachrichten (wie Du), manchmal treten die Fehler aber auch an einer anderen Stelle auf - und erst auf Nachfrage sehen die Betroffenen die OOM Killer Nachrichten im System Log.

Im Laufe der Zeit bekommt man da eine gewisse Routine. Wenn Betroffene merkwürdige Fehler berichten und es ein in C++ geschriebenes Paket ist, denke ich fast immer automatisch an den OOM Killer. Und die bis zu 2 GB pro Job RAM ist der Erfahrungswert, den wir dort im Laufe der Zeit gesammelt haben. Der Wert ist also nicht vom Himmel gefallen oder geraten. Ich vermute, dass es im Laufe der Zeit noch mehr werden wird.

Das Vorgehen ist aber immer gleich:

Runtergehen auf "-j1". Wenn es dann geht, lag es an zu wenig RAM

Wenn es "-j1" auch nicht funktioniert, ist es ein anderes Problem - aber man hat zumindest ein gutes Build-Log, in dem nicht alle Jobs durcheinander loggen.

Von daher mach bitte folgendes

Übersetze das Paket bitte mit -j1

Wenn es dann immer noch Fehler gibt, poste bitte die vollständige OOM Killer Nachricht aus dmesg, die Ausgabe von "emerge --info" und die letzten 200 Zeilen des Build Logs.

Dann können wir weitersehen.

Was C++ an sich betrifft: der Vorwurf, dass C++ Code Bloat verursacht und viel Speicher benötigt, ist so alt wie C++ selbst. Ich erinnere mich an ein Interview mit Stroustrup aus den 90ern, in dem er den Code Bloat auch einräumt, aber versichert, dass das Problem wohl bald gelöst sein wird. Hat wohl nicht funktioniert. Alle ärgern sich über die langen Compilier-Zeiten und den großen Resourcen-Bedarf - aber bisher hat noch keiner ein Mittel dagegen gefunden. 

PS: Hier werden ein paar Gründe für den Code Bloat beschrieben: https://dirtyhandscoding.github.io/posts/on-cpp-code-bloat.html

----------

## alexander_ro

Ja ich kenne die Beschwerden warum hat der böse Kernel mein tooles Programm gekillt. Sind ja sooo viele andere da ... hätte er nicht ...

Ja stimmt er killt nicht immer das Problemprogramm aber im meinem Fall hat er genau getroffen.

Der versucht das System am laufen zu halten ... ich kenne keinen einzigen Fall in dem das killen eines Programms nicht berechtigt gewesen wäre.

Was sollte Deiner Meinung nach der Kernel tun wenn der Speicher aus ist?

Die C++ Vorwürfe sind so häufig wie meistens falsch. Es ist eine Frage des Designs ob man mit 16 GB Speicher auskommt oder halt eben nicht.

Dann hast Du den Satz sicher gesehen (ganz am Anfang):

Klingt für mich sehr nach Design Fragen und nicht nach unabwendbarem Zwang.

```

In fact, it is caused by bad habit or writing code in headers, severely worsened by C++ templates and inspired by STL itself.

```

Gegen lange Bauzeiten kann man bei großen Programmen wenig tun. Besonders wenn Menschen die den Zweck nicht verstanden haben Templates bauen lässt. Aber gegen überbordenden Speicher Verbrauch beim Linker sehr wohl. Microsoft war bisher der Platzhirsch für schlechtes C++ Design sind jetzt offensichtlich auf Platz zwei verdrängt worden.

Interview mit Stroustrup er hat aber auch gesagt das die meisten nicht verstanden haben wie man diese Mechanismen in C++ Anwendet. Es hat auch nicht funktioniert das den Menschen bei zu bringen. Ganz besonders scheinbar bei den Machern von clang und llvm. Das sind die einzigen die kaputt gehen nach 16GB Speicherverbrauch ...

Ich habe das Problem schon gelöst und die Software entfernt wie gesagt ich brauche den Mist nicht und wenn Mozilla glaubt das ein Vendor Lock das Mittel der Wahl ist bei freier Software dann haben die auch was nicht verstanden. Deshalb sind die jetzt gleich mit vom System geflogen. Problem gelöst ...  :Smile: 

----------

## franzf

 *alexander_ro wrote:*   

> Ich schau auf den Text und das macht es nicht also ist mindestens der Text falsch

 

Ich denke nicht dass das ebuild falsch ist.

 *Quote:*   

> naja vielleicht ist auch meine Übersetzung des Textes falsch. Nicht meine Schuld das es keinen Deutschen gibt.

 

Kannst ja mal anregen, ebuilds zu übersetzen, um die Einstiegsbarriere zu verkleinern. -> bugs.gentoo.org

bugs.gentoo.org ist generell ein guter Einstiegspunkt, wenn es um Probleme geht. Die Wahrscheinlichkeit, dass sich schon jemand zu einem Problem geäußert hat, ist recht hoch.

Suchen nach "ALL firefox clang" liefert dann u.A. das hier: https://bugs.gentoo.org/637576

Es hat also etwas mit rust zu tun. Gebraucht wurde es anfangs für Stylo.

Keine Ahnung, wie das alles aktuell aussieht. Gentoo-Tree über github interface browsen ist zeitraubend. Kann sein dass Stylo nicht mehr optional ist oder andere Teile von firefox das auch brauchen.

// EDIT: Und der ganze Aufwand für die Katz, weil es dich eh nicht (mehr) interessiert.

----------

## alexander_ro

Ich meinte diesen Text der da Erklärend daneben steht.

```

clang                : Use Clang compiler instead of GCC

```

Ich verstehe den so das man damit sagt er soll das mit clang bauen und nicht mit gcc. Dann sollte ein -clang das Problem lösen. Das tut es aber scheinbar nicht (Firefox). Ist nun aber auch egal.

Rust war das nicht auch so eine Webseiten Generator Sprache wie PHP die im Internet Hype kurz vor 2000 entstanden ist ... bin mir nicht sicher. Danke fürs Nachschauen aber ich lasse das jetzt mit den Mozilla Sachen. Mir macht das clang und llvm zu viele Probleme schon lange als das ich es nur wegen einer Abhängigkeit mitschleppen wollte.

----------

## franzf

 *alexander_ro wrote:*   

> Rust war das nicht auch so eine Webseiten Generator Sprache wie PHP die im Internet Hype kurz vor 2000 entstanden ist

 

Nö, ist ne kompilierte Programmiersprache, die ein Augenmerk auf Sicherheit legt. https://de.wikipedia.org/wiki/Rust_(Programmiersprache)

Mozilla hat das entwickelt und ersetzt nach und nach Teile des Browsers durch rewrites in rust.

----------

## alexander_ro

Rust verlangt nach dem Wikipedia aber kein clang angeblich nur llvm.

Nach einem:

```

emerge --ask rust

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] dev-lang/rust-1.43.1 

Would you like to merge these packages? [Yes/No] no

Quitting.

```

nicht mal llvm.

----------

## franzf

 *alexander_ro wrote:*   

> Rust verlangt nach dem Wikipedia aber kein clang angeblich nur llvm.
> 
> Nach einem:
> 
> ```
> ...

 

mach emerge --ask --verbose dev-lang/rust und du siehst USE=-system-llvm

Wegen clang hab ich den bugreport zitiert (der auch schon bundled-llvm erwähnt). USE=clang gibt es bei rust nimmer.

Kannst ja nachfragen, ob die Abhängigkeit tatsächlich noch benötigt wird. Ich gehe davon aus, dass dem so ist.

----------

## alexander_ro

Hm, ich dachte der würde dann fehlende Pakete mit zur Installation auswählen. Gibt ja sonst kein lauffähiges Programm.

----------

## franzf

 *alexander_ro wrote:*   

> Hm, ich dachte der würde dann fehlende Pakete mit zur Installation auswählen. Gibt ja sonst kein lauffähiges Programm.

 

Das rust-sourcepaket  bringt llvm mit, weil es dadurch garantiert, dass es 100% lauffähig ist. In Gentoo will man gerne den Kompilieraufwand vermeiden und sicherheitspatches zentral in libs einpflegen, weshalb es die systemweite Option gibt, per USE="system-llvm" den per portage installierten llvm zu verwenden.

Wenn USE="-system-llvm" gesetzt ist wird der mitgebrachte llvm verwendet.

USE="system-llvm" ist für dev-lang/rust via package.use.stable.mask deaktiviert:

https://github.com/gentoo/gentoo/blob/293314869a4a70ff5537f0b0e30c788ff4b9957d/profiles/base/package.use.stable.mask#L84

Keine Ahnung, ob das so noch aktuell ist.

Kurz: dev-lang/rust zieht in deiner Konfiguration kein llvm als Abhängigkeit, weil es diese Abhängigkeit selbst mitbringt (und baut).

----------

## Josef.95

Naja, bei anderen Leuten bauen diese Pakete auch mit nur 2 GB RAM im Rechner.

Wie auf mehrfache Nachfrage mal das build.log und die emerge --info posten hätte vermutlich weiterhelfen können.

----------

## alexander_ro

@franzf

Ja so vermeidet man Redundanzen sehr löblich von Gentoo ... bei mir ist es aus ok ... aber wer weiß das. Die meisten werden es einfach installieren und dann doppelt haben.

Nur das ich es richtig verstehe. Die bauen mit rust wegen Sicherheit und llvm wegen Optimierung schnell weniger Speicherbedarf. Verdoppeln dann aber den Ressourcen Verbrauch auf den Anwender Rechnern weil die llvm redundant zu anderen llvm Installationen erzwingen. 

Zu dem was die Projektmacher da tun schreib ich jetzt nix sonst heißt es wieder ich nerve ...

@Josef.95

Die 10er Version mit 2GB?

Naja bis vor kurzem wollte mir jeder das noch als den Norm Zustand verkaufen ...

Wenn ich nachher ein bisschen Zeit habe baue ich es nochmal die alten Sachen hat der entfernt. Aber das log wird sicher recht unhandlich sein soll man das wirklich in ein Forum kopieren?

----------

## Max Steel

 *alexander_ro wrote:*   

> Wenn ich nachher ein bisschen Zeit habe baue ich es nochmal die alten Sachen hat der entfernt. Aber das log wird sicher recht unhandlich sein soll man das wirklich in ein Forum kopieren?

 

Nein.

Aber dank pastebin.com und ähnlichen Seiten auch garnicht nötig.

(das Package wgetpaste erleichtert dir die Handhabung mit Logfiles.) einfach mit cat reinpipen und fertig ist die laube.

----------

## mike155

 *alexander_ro wrote:*   

> Was sollte Deiner Meinung nach der Kernel tun wenn der Speicher aus ist?

 

Ganz einfach: dem Programm, das den Speicher anfordert sagen, dass kein Speicher mehr vorhanden ist. Dafür gibt's ENOMEM.

Was stattdessen passiert ist: der Kernel sagt dem Programm, dass es den Speicher bekommt. Und erst dann, wenn das Programm den Speicher nutzen will, sagt der Kernel: Mist! Jetzt habe ich ein Problem! Da habe ich wieder mal mehr versprochen, als ich halten kann. Was mache ich jetzt? Hmmm. Ach ja, ich könnte ja irgendeinen Prozess abschießen, dann bekomme ich wieder freien Speicher. Hallo OOM-Killer: bitte mach doch mal die Drecks-Arbeit!

----------

## franzf

 *alexander_ro wrote:*   

> Nur das ich es richtig verstehe. Die bauen mit rust wegen Sicherheit und llvm wegen Optimierung schnell weniger Speicherbedarf. Verdoppeln dann aber den Ressourcen Verbrauch auf den Anwender Rechnern weil die llvm redundant zu anderen llvm Installationen erzwingen. 
> 
> Zu dem was die Projektmacher da tun schreib ich jetzt nix sonst heißt es wieder ich nerve ...

 

Ähm, naja.

1) rust ist ein compiler. rust-Programme brauchen die llvm nicht, von dem her ist es schnurz piep für den user, ob rust seine eigene llvm mitbringt.

2) rust ist ein compiler. Der Output muss reproduzierbar sein. Dafür gibt es eine fette testsuite. Da upgrades von llvm zu (evtl. von den tests nicht abgedeckten) Problemen führen können, ist es wichtig, dass rust genau weiß, mit welchem LLVM es keine Probleme gibt. Vor einem Upgrade dieses llvm gibt es zig Tests. Weil man nicht weiß, mit welchem LLVM der user rust bauen/ausführen wird (und auch mit welchen Compiler-Optionen der gebaut ist), ist es WICHTIG, dass rust so gebaut werden kann, dass er 100% das macht, was die rust-Entwickler angedacht haben.

3) LTS Distributionen... Die liefern oft viel zu alte Versionen von fast allen Libraries mit. Das ist auf Dauer nicht managebar, insbesondere wenn neue Features wirklich gebraucht werden. Daher muss rust den llvm einfach selber mitbringen.

Und bevor du schreibst, was der llvm fürn Mist ist, dass man sich auf den nicht verlassen kann, hier zwei bugs in gcc, von denen ich betroffen bin:

https://github.com/Beep6581/RawTherapee/issues/5749

RT kompiliert problemlos, aber die Bilder haben alle einen Violetten Schleier. gcc-10 bug.

http://lua-users.org/lists/lua-l/2020-07/msg00001.html

lua crasht,wenn man tostring mit nem float aufruft. gcc-10 bug.

----------

## alexander_ro

@Mike155

Ist der Kernel jetzt das Kindermädchen für Entwickler? Meiner Meinung nach ist es Aufgabe des Programmierers dafür zu sorgen das er nicht blindwütig Speicher verbraucht und nie wieder frei macht. Es ist aber durchaus möglich über Systemschnittstellen fest zu stellen ob noch genügend Speicher vorhanden ist. Physischer Speicher ist Endlich das haben die Programmierer nur vergessen. Das der Kernel die Aussage nicht machen kann ist eigentlich logisch. Es würde heißen das man alle Vorteile des virtuellen Speichers und der Speichernutzung das man nur Daten kopiert die geschrieben werden über Bord werfen muss. Man wäre wieder auf dem Stand von vor 30 Jahren das man exakt nur den Physisch vorhandenen Speicher belegt auch wenn er gar nicht gebraucht wird und ein anderes Programm nicht laufen kann obwohl der Speicher ausreichen würde. Das wäre für Programmierer Bequem für den Enduser aber ein Riesiger Nachteil. Nicht alle haben so viel Geld wie Du das sie einfach zig GB mehr einbauen in den Rechner ohne zu wissen ob er jemals gebracht wird. Google würde einen Schreikrampf bekommen wenn die nur auf verdacht zig GB in jedem Rechner mehr brauchen. Ich schätze in deren Größenordnung eine halbe bis eine Milliarde Mehrkosten für was ... ja genau für was ein Bequemes Programmierer leben. Das werden die nicht zahlen wollen. Von den Verbrauchten Ressourcen für die Produktion von Speicher der eigentlich nicht wirklich genutzt wird. Menschen sollten langsam mal anfangen die noch vorhandenen Mittel mit Hirn zu verwenden. 

@franzf

zu 1,2) Entwickler sind also keine User ah ... gut kann man so sehen. Aber das ist schon mal ein Punkt das den Speicher Verbrauch aufbläht ohne das C++ da was für kann. Das sind Unterschiedliche Binärdateien der beiden llvms der Kernel hält die doppelt im Speicher. clang benutzt aber auch einen externen llvm die brauchen also keine Reproduzierbaren Ergebnisse?

zu Rest) Die Argumente gelten für jede Software das ist kein alleine Rust Problem also wenn alle Compiler damit anfangen alles selbst mitzubringen dann wird es eng das man Software überhaupt noch außerhalb eines Supercomputers bauen kann. Ich habe geschrieben das clang Mist ist weil man den mit 16GB nicht bauen kann. Schön für Dich wenn Du unbegrenzten Speicher hast hab ich nicht. Auch habe ich nie behauptet das andere Programme keine Probleme haben. Ihr habt geschrieben das mehr als 16GB Speicherverbrauch erstens normal ist und das alle größeren Projekte haben beides ist aber falsch.

Der baut gerade den clang das dauet aber clang llvm und noch einige andere Sachen die einer der beiden braucht.

----------

## franzf

 *alexander_ro wrote:*   

> Ist der Kernel jetzt das Kindermädchen für Entwickler? Meiner Meinung nach ist es Aufgabe des Programmierers dafür zu sorgen das er nicht blindwütig Speicher verbraucht und nie wieder frei macht.

 

Dann schreibst du jetzt sicher bugreports für ld.bfd (->binutils) und gcc, dass die gefälligst prüfen sollen, ob genug Speicher vorhanden ist für das was sie tun.

 *Quote:*   

> zu 1,2) Entwickler sind also keine User ah

 

Entwickler sind üblicherweise user mit leistungsfähigeren Rechnern (oder mehr Planung und Geduld beim Kompilieren als normele User, die während dem Kompilieren Counter Strike spielen und youtube schauen wollen).

Ich sprach vom Firefox-User.

 *Quote:*   

> clang benutzt aber auch einen externen llvm die brauchen also keine Reproduzierbaren Ergebnisse?

 

Du hättest in der Vergangenheit besser deine emerge-Ausgaben gelesen, Dann wäre dir aufgefallen, dass clang und llvm immer zusammen aktualisiert werden. Das liegt daran, dass sie parallel entwickelt werden. Commits, die die API von LLVM ändern (oder andere Seiteneffekte haben) ziehen auch eine Anpassung von clang nach sich. Deshalb ist der llvm, den clang verwendet, nicht wirklich extern.

 *Quote:*   

> zu Rest) Die Argumente gelten für jede Software das ist kein alleine Rust Problem also wenn alle Compiler damit anfangen alles selbst mitzubringen dann wird es eng das man Software überhaupt noch außerhalb eines Supercomputers bauen kann.

 

Schau mal, was gcc mit bundled, dir wird schlecht werden. libffi, libgo uswusf... Aber wie bei clang ist das OPTIONAL!!! Verstehst du, was optional heißt? Dass das bei Gentoo gerade nicht der Fall ist, da kann weder firefox noch rust noch clang was für. Wenns dich stört löse die package.use.stable.mask und kompilier rust mit system-llvm. Wenns klappt mach nen bugreport auf.

 *Quote:*   

> Ich habe geschrieben das clang Mist ist weil man den mit 16GB nicht bauen kann. Schön für Dich wenn Du unbegrenzten Speicher hast hab ich nicht.

 

Ich hatte nie Probleme, clang auf nem System mit 4GB RAM zu kompilieren. Aber vielleicht lag es ja daran, dass ich clang zum Kompilieren von clang verwendet habe...

 *Quote:*   

> Auch habe ich nie behauptet das andere Programme keine Probleme haben. Ihr habt geschrieben das mehr als 16GB Speicherverbrauch erstens normal ist und das alle größeren Projekte haben beides ist aber falsch.

 

Wo wurde das geschrieben? Es war die Rede von 2GB pro C++ compilation unit, und linken kann nochmal mehr brauchen. Im Gegenteil, build.log und emerge --iinfo wurden gefordert, um zu sehen, ob evtl. woanders Prbleme liegen.

----------

## alexander_ro

Nein weil mir das völlig Wurst ist wenn ich nicht gerade einen clang übersetzen muss hatte ich seit Jahrzehnten keinen Prozesser der vom OOM gekillt wurde.

"Entwickler sind üblicherweise user mit leistungsfähigeren ... " vielleicht in den Industrienationen die Oberschicht sonst niemand.

Dann sollten die in Zukunft clang llvm und rust zusammen entwickeln. Trotzdem unwahrscheinlich das zwei Projekte die Parallel von verschiedenen Menschen Entwickelt werden keine Problem in der Zusammenarbeit haben. Gab es noch nie in der realen Welt nur in Akademischen Thesen geht das. Im Gensatz zu Rust mit einer fixen llvm Version haben die nur eine Dynamik die sie Beherrschen müssen. clang und llvm hat zwei Dynamiken die die aufeinander Anstimmen müssen. Vergiss es das funktioniert nicht auf dauern. Die NASA hat wegen solchem Schwachsinn in der Software Entwicklung schon viele Milliarden Dollar in Rauch und Asche verwandelt.

Nein muss ich gar nicht wissen weil mir das auch Wurscht ist was wer zusammen kloppt. Im Gegensatz zu clang kann ich den gcc Problemlos Übersetzen. Hätte clang das auch geleistet hätte ich nie einen Gedanken auf das DIng verschwendet. Im übrigen wart ihr das die Behauptet habe bei C++ Programmen sind >16GB Memory verbrauch normal. Das mit dem llvm Doppeln war nur ein Beispiel für schlechtes Design das Speicher Frist.

Ist mir ebenfalls Wurscht wenn es bei Dir geht bei mir geht es nicht und zuvor hatte ich schon mal gefragt ob das die Version 10 war da habe ich aber keine Antwort mehr bekommen. Bis zur 9 ging es bei mir auch noch.

Oben in den Beiträgen wurde das so dargestellt das große C++ Programme viel Speicher brauchen. Da ihr wusstet um wie viel Speicher es ging habe daraus folgerichtig abgeleitet das >16GB eurer Meinung nach normal sind. Wärt ihr nicht dieser Meinung gewesen hätte vielleicht mal jemand anmerken sollen das >16GB vielleicht doch ein kleines bisschen zu viel ist. Solcher Text steht da oben aber nirgends. Um genau diesen Umstand ist dann der Streit entbrannt. Lies mal den Anfang nochmal ... da hat keiner Zusätzliche Daten gefordert. Es wurde nur beleidigt der clang beschützt vor meiner Dreisten Idee er könnte ein bisschen kaputt sein mit >16GB Memoryverbrauch und Crash beim bauen.

<Edit>

Der clang bau rödelt noch ... Momentan ist er bei 1GB SWAP Verbrauch RAM ist noch verfügbar war aber scheinbar schon mal knapp sonst wäre der 1GB nicht ausgelagert worden. Es laufen aber nur die ccp1plus Prozesse also der C++ Compiler. Problem gab es ja erst beim linken. Wobei ich nicht weiß wie die ihre Programme zusammen bauen.

</Edit>

----------

## franzf

Jesus!

clang und llvm WERDEN ZUSAMMEN IN EINEM REPO ENTWICKELT! Drum klappt da auch alles.

bundled-llvm in rust ist OPTIONAL! Nur eben (zur Zeit) in Gentoo nicht wegen gemasktem USE-Flag bei ner stable Installation.

Und da du scheinbar wirklich nicht interessiert bist an dem, was ich schreibe, und lieber wild spekulierst ohne vorher nachzuschauen, war das mein letzter Post hier.

Hat genug Zeit gekostet.

----------

## alexander_ro

Das mit dem Pastebin geht nicht weil ich kein Pro User bin. Das Forum kackt ab wenn man es einfügen möchte was soll ich jetzt mit dem Log machen?

```

You have exceeded the maximum paste size of 512 kilobytes per paste. PRO users don't have this limit!

```

Dieses mal habe ich den Rechner benutzt als der Speicher alle war. Das merkte man sofort und hat leider die Antwort auf das letzte Post von franzf gefressen.

Grob stand da das mich die clang Lobeshymnen nicht interessieren weil ich das Ding nicht benutze. Das ist für mich eine Unnütze Abhängigkeit die nervt weil kaputt. Nicht bauen können also kaputt. clang 9 war noch heil weil bauen kionnte. Was ich bisher benutzt habe war Firefox und Thunderbird. Die werden nun entfernt clang und llvm waren schon weg. Die habe ich jetzt nur neu gebaut damit Ihr euer Wunschlog bekommt und nun ist das blöde Teil so groß das  ich es nicht zu euch bekomme ...  :Sad: Last edited by alexander_ro on Mon Jul 06, 2020 7:25 pm; edited 1 time in total

----------

## alexander_ro

Das Info Ding ist nicht so groß.

```

alien /home/alex # emerge --info clang

Portage 2.3.99 (python 3.7.7-final-0, default/linux/amd64/17.1/desktop, gcc-9.3.0, glibc-2.30-r8, 5.4.48-gentoo-x86_64 x86_64)

=================================================================

                         System Settings

=================================================================

System uname: Linux-5.4.48-gentoo-x86_64-x86_64-Intel-R-_Core-TM-_i7-2670QM_CPU_@_2.20GHz-with-gentoo-2.6

KiB Mem:     8120236 total,   6298472 free

KiB Swap:   10485756 total,   9315444 free

Timestamp of repository gentoo: Sun, 05 Jul 2020 18:30:01 +0000

Head commit of repository gentoo: 475920e39e05fb128e3a00af1f98e8d0b5c4a4f2

sh bash 5.0_p17

ld GNU ld (Gentoo 2.33.1 p2) 2.33.1

app-shells/bash:          5.0_p17::gentoo

dev-lang/perl:            5.30.3::gentoo

dev-lang/python:          2.7.18::gentoo, 3.6.10-r2::gentoo, 3.7.7-r2::gentoo, 3.8.2-r2::gentoo

dev-util/cmake:           3.16.5::gentoo

dev-util/pkgconfig:       0.29.2::gentoo

sys-apps/baselayout:      2.6-r1::gentoo

sys-apps/openrc:          0.42.1::gentoo

sys-apps/sandbox:         2.18::gentoo

sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r4::gentoo

sys-devel/automake:       1.16.1-r1::gentoo

sys-devel/binutils:       2.33.1-r1::gentoo

sys-devel/gcc:            9.3.0::gentoo

sys-devel/gcc-config:     2.3::gentoo

sys-devel/libtool:        2.4.6-r6::gentoo

sys-devel/make:           4.2.1-r4::gentoo

sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)

sys-libs/glibc:           2.30-r8::gentoo

Repositories:

gentoo

    location: /usr/portage

    sync-type: rsync

    sync-uri: rsync://rsync.gentoo.org/gentoo-portage

    priority: -1000

    sync-rsync-extra-opts: 

    sync-rsync-verify-max-age: 24

    sync-rsync-verify-jobs: 1

    sync-rsync-verify-metamanifest: yes

local-crossdev

    location: /usr/local/portage

    masters: gentoo

    priority: 9999

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="@FREE"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-O2 -pipe -ggdb"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-O2 -pipe -ggdb"

DISTDIR="/usr/portage/distfiles"

ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"

FFLAGS="-O2 -pipe"

GENTOO_MIRRORS="http://distfiles.gentoo.org"

LANG="de_DE.UTF-8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LINGUAS="de"

MAKEOPTS="-j4"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"

PORTAGE_TMPDIR="/var/tmp"

USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cddb cdparanoia cdr cli crypt cups dbus dri dts dvd dvdr egl elogind emboss encode exif flac fortran gdbm gif gles2 gpm gtk iconv icu ipv6 jpeg lcms ldap libnotify libtirpc lock mad minizip mmx mng mp3 mp4 mpeg multilib ncurses nls nptl ogg openmp pam pango pcre pcre16 pdf png policykit ppds qt5 readline sdl seccomp session spell split-usr sqlite sse sse2 ssl startup-notification svg tcpd thunar tiff truetype udev udisks unicode upower usb v4l v4l2 vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" RUBY_TARGETS="ruby25" USERLAND="GNU" VIDEO_CARDS="intel i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

----------

## mike155

 *Quote:*   

> 
> 
> ```
> CFLAGS="-O2 -pipe -ggdb" 
> ```
> ...

 

Ich könnte mir vorstellen, dass es an "--ggdb" liegt.

So etwas in dieser Art: https://gcc.gnu.org/legacy-ml/gcc/2019-04/msg00270.htmlLast edited by mike155 on Mon Jul 06, 2020 7:40 pm; edited 1 time in total

----------

## alexander_ro

Warum?

----------

## Josef.95

Vermutlich fehlt einfach noch das Verständnis das man mit den vielen CPU-Cores und Threads die man heute verfügbar hat, nicht einfach die make Jobs hochstellen kann, ohne für genug RAM zu sorgen.

Und ja, ich denke das man mit 2GB RAM (und ein wenig swap) auch llvm:10 und clang:10 noch mit einem Job gebaut bekommt.

----------

## mike155

 *alexander_ro wrote:*   

> Warum?

 

Ich habe oben noch einen Link eingefügt.

----------

## alexander_ro

Schön wenn Du das glaubst ... ich habe den Beweis erbracht das Dein glaube falsch ist.

----------

## alexander_ro

Vielen CPU Cores na jetzt aber übertreib nicht so es sind nur vier ...

Ich habe jedenfalls den Beweis erbracht das Dein glaube falsch ist es geht nicht ... >16Gb ist schon eine Hausnummer ... ???

<Edit>

Zuerst Mekert das Forum das es den Beitrag nicht haben will und dann ist er doch da ... na gut dann halt zweimal fast der gleiche Text.

</Edit>

----------

## alexander_ro

Hier das Log: wieder gelöschtLast edited by alexander_ro on Mon Jul 06, 2020 8:56 pm; edited 1 time in total

----------

## firefly

 *alexander_ro wrote:*   

> Schön wenn Du das glaubst ... ich habe den Beweis erbracht das Dein glaube falsch ist.

 

Nope hast du nicht komplett sondern nur für dein Setup (mit dem -ggdb parameter)

Und wenn das wirklich ein Problem wäre (auch ohne den -ggdb parameter) würden deutlich mehr Fragen/Bugreports zu diesem Thema geben, was es aber nicht tut.

----------

## alexander_ro

Selber Nope spar Dir die Blöden Sprüche wenn Du nichts sinnvolles zu sagen hast.

<Edit>

Du Schlaumeier warum ging das dann noch mit der Version vorher Problemlos wenn es doch angeblich mit dem Parameter gar nicht gehen kann.

</EDit>Last edited by alexander_ro on Mon Jul 06, 2020 7:55 pm; edited 1 time in total

----------

## Josef.95

Uff, mein Vorschlag war es mit MAKEOPTS="-j2" zu testen --> https://forums.gentoo.org/viewtopic-p-8478040.html#8478040

(wurde aber schlicht und einfach ignoriert :-/)

Sorry, ich bin hier auch erst mal raus.

----------

## firefly

 *alexander_ro wrote:*   

> Selber Nope spar Dir die Blöden Sprüche wenn Du nichts sinnvolles zu sagen hast.
> 
> <Edit>
> 
> Du Schlaumeier warum ging das dann noch mit der Version vorher Problemlos wenn es doch angeblich mit dem Parameter gar nicht gehen kann.
> ...

 

LOL Wenn man meint Beleidigen zu müssen dann will man wohl keine hilfe -> und tschüss

----------

## alexander_ro

Ich mach den Scheiß ja nur wegen euch ich habe schon gefühlt 100 Beiträge vorher geschrieben das Firefox Thunderbird mit allem gedöhns vom den Rechnern fliegen. Und ihr Jammert mich jetzt an das es Zeit kostet. Ich hätte das schon längst beendet. Ja danke für nichts ....

----------

## alexander_ro

Wer hat denn mit den Beleidigungen angefangen und Tschüss ja Du bist gut weiter.

Ich brauch so blöde Sprüche echt nicht wie bereits geschrieben hätte ich Thema schon lange beendet. Wenn man nicht unbdingt das blöde Log gewollt hätte.

----------

## mike155

Da mein Link zu dem Bug, der das Problem beschreibt (https://gcc.gnu.org/legacy-ml/gcc/2019-04/msg00270.html), ja niemanden interessiert und es auch angezweifelt wird, dass es an "-ggdb" liegen könnte, bin ich auch raus....

----------

## alexander_ro

Warum? Ist also Anzweifeln ... gehts noch ...

Warum bitte ging das dann mit Version 9 noch wenn es doch zu unmöglich ist das das gehen kann???

Behauptungen Aufstellen ohne Logisch Zusammenhänge zu beachten ist leicht. Sein alt ist der Bug auch noch und es ist nicht die gcc Version die ich benutze. Euch ist es doch Scheißegal ob da irgendwas einen Logischen Zusammenhang hat Hauptsache euer clang Baby steht im richtigen Licht.

Und ich bin jetzt der Schuldige weil ich den Mist gemacht habe den ihr haben wolltet ja wie gesagt danke für nichts ...

----------

## mike155

Es gibt sogar einen Gentoo Bug zu dem ggdb Problem: https://bugs.gentoo.org/626134. Der bezieht sich zwar auf Rust, gilt aber vermutlich ebenso für clang.

----------

## alexander_ro

Gehts noch älter der ist von 2017 und noch weniger die Version die ich verwende. Rust kann ich ohne Probleme bauen und clang 9 auch nur 10 nicht.

<Edit>

Ich habe jetzt die Option entfernt und baue das clang Ding neu. Mal gucken was es sagt ...

</Edit>

----------

## Josef.95

@mike155

Jo, guter Fund :)

@alexander_ro

Ich wage es noch eine These aufzustellen (ich hoffe das sie keine weiteren Explosionen nach sich zieht :P)

 *build.log wrote:*   

> 
> 
> ```
>  * If you need support, post the output of `emerge --info '=sys-devel/clang-10.0.0::gentoo'`,
> 
> ...

 

Ich denke wenn man diese Infos wie empfohlen gleich mit bereitgestellt hätte, dann hätte man wahrscheinlich wesentlich besser weiterhelfen können.

----------

## alexander_ro

Ich hatte das nicht mehr weil ich bereits sehr früh auch geschrieben habe das ich die Mozilla Software entferne. Weil ich nicht einsehe mir diktieren zu lassen was meine Toolchain ist.

Habe es ja jetzt gemacht das Build-Log ist einige Posts weiter oben verlinkt. Ich habe es aber wieder gelöscht weil ich nicht den Eindruck hatte es würde jemanden interessieren. Wenn man solche Monster Logs haben will sollte das Forum aber auch eine Möglichkeit haben wie man die zur Verfügung stellt. Pastebin geht es nicht ist zu groß wenn man kein Pro User ist. Ich vermute das sind die die dafür zahlen. War nicht meine Absicht.

----------

## alexander_ro

Wenn man die Option für die Debugsymbole entfernt kann man den zwar Übersetzen aber halt auch so gerade eben. Bei der nächsten Version ist es Vermutlich wieder kaputt. Ist auch kein Wunder das es ein wenig Speicher spart. Es ändert nur nichts das das schlechte Design des clang beim bauen exorbitant Speicher verbrät. Ich habe mir das Paket mal ausgepackt und angeschaut irgendwo in den Beiträgen oben war in einem Link erklärt wo die Problem bei den schlechten Angewohnheiten der C++ Programmiere liegen. clang hat konsequent alles so gemacht das es möglichst schlecht ist. Klasse Leistung.

Mir nutzt das aber auch nichts weil ich erstens die Debugsymbole brauche ich suche des öfteren DInge die nicht funktionieren in allem Möglichen an Software. Da es zu den meisten Sachen keine Brauchbare Dokumentation gibt bleibt oft nur die Möglichkeit den Debugger zu befragen was das abläuft. Ich habe aber keine Lust dann jedes mal Mühsam alle Teile zusammen zu suchen und wieder zu warten bis das neu Compiliert ist um dann Endlich mal Stunden später einen Blick darauf werfen zu können.

Es ist leider Modern geworden Schlechtes Design und die damit verbundenen Probleme auf den Compiler zu schieben. Richtig sind solche Beschuldigungen eher selten ...

Ich hau den Mist jetzt wieder runter und freue mich das laut dem System Monitoring der Aufwand für emerge um >50% sinkt wenn Thunderbird, Firefox, clang, rust und ein bisschen klein Kram weg sind. Schon eine Leistung wenn vier Programme mehr Leistung bei den Updates fressen als der ganze Rest des Systems.

----------

## Max Steel

Kleine Anmerkung dazu: auf meinem Geschäftslaptop mit 6GB RAM und 8 Cores (AMD Ryzen 2nd Gen mit Vega GPU) kann ich problemlos -j5 bauen. nur sollte ich während dem Paket "chromium" keinen nutzbaren Desktop erwarten (er wird swappen, heißt mit einem kleineren -j könnte ich da die Buildtime vermutlich noch drücken). Buildtime bei 8,5 Stunden. firefox habe ich hier nur in der -bin Version installiert.

llvm braucht 1 Stunde, clang etwa 1 Stunde und rust etwa 1,5 Stunden

Auf meinem Arbeitsdesktop (Specs sind unten in der Signatur) ist die selbstbau Version installiert.

Dort sieht das Verhältnis folgendermaßen aus:

chromium -> 8,5 Stunden

llvm -> 30 Minuten

clang -> 1 Stunde

rust -> 1,5 Stunde

firefox -> 1,5 Stunden

Achja. warum ich firefox auf dem Arbeitslaptop in der -bin installiert habe? Needs... chromium war unbrauchbar (mitten im Update und zusätzlich ständige Crashes weil die Abhängigkeiten gerade ebenfalls nicht zusammenpassten) und ich brauchte mal eben einen Browser... also firefox-bin installiert. und seitdem ist der da...

llvm und clang hab ich installiert weil ich thunderbird Nutzer bin.

----------

## alexander_ro

Bei meinem letzten Versuch brauchte clang bei mir >4Stunden mit -j4. Ist halt ein älterer core-i7.

Zu allem was Google an Browser baut kann ich nichts sagen habe ich nie benutzt.

Ich habe bis jetzt Firefox und Thunderbird auch benutzt. Ist eine gute Gelegenheit die los zu werden.

----------

## Max Steel

 *alexander_ro wrote:*   

> Bei meinem letzten Versuch brauchte clang bei mir >4Stunden mit -j4. Ist halt ein älterer core-i7.
> 
> Zu allem was Google an Browser baut kann ich nichts sagen habe ich nie benutzt.
> 
> Ich habe bis jetzt Firefox und Thunderbird auch benutzt. Ist eine gute Gelegenheit die los zu werden.

 

Verstehe mich nicht falsch. Aber alleine diese Diskrepanz würde mich dazu bewegen einen möglichen Fehler in meiner Konfiguration oder Probleme in meiner Hardware/meinem Hardwaresetup nicht auszuschließen...

ein i5-3470 würde ich jetzt nicht unbedingt als die schnellste Gurke unter der Sonne bezeichnen wollen.

und dass der "alte" Prozessor (mit ausreichend RAM) mit einem Ryzen 2nd Gen (der mindestens 5 Generationen jünger ist) gleichziehen kann ebenfalls...

----------

## alexander_ro

Nachdem Setup und Hardware mit allem (995 Pakete) Problemlos klar kommt außer jetzt mit clang?

Würdest Du dann Dein gesamtes Setup in Frage stellen und was tun?

Alles neu installieren ...

<Edit>

Was den langsam macht ist die SWAP Benutzung das wundert nicht. Ist zwar eine SSD aber im Vergleich zu RAM sind die Arsch langsam.

Bei den anderen Sachen kommt der mit dem RAM beim Bauen aus. Deshalb laufen die sehr viel schneller. Eigentlich Logisch.

</Edit>

----------

## Max Steel

Ich würde erstmal mögliche Temperaturprobleme versuchen zu identifizieren (Temperatur zu hoch -> CPU drosselt sich zum schutze -> langsamerer Compile)

USE-Flag Diskrepanzen?

der Kernel hat als Basis von allem auch etwas damit zu tun. Mögliche Konfigurationsprobleme im Kernel im Bereich Processor and System könnten auch was damit zu tun haben. Je nachdem wie alt das System ist und wie lange Zeugs mitgeschliffen wird.

Ist der Build vll durch den Build auf eine HDD (/var/tmp/portage auf die HDD statt auf ein tmpfs) verlangsamt?

Mögliche Stolperfallen gibts viele  :Wink: 

(lsblk, mount und df -h /var/tmp/portage können bei letzterem helfen)

btw:

auf dem Arbeits-PC läuft /var/tmp/portage in einem tmpfs. Auf dem Laptop auf der NVMe SSD da die 6GB RAM mir dafür etwas zu knapp für meinen Geschmack sind.

----------

## alexander_ro

Ja würde ich Probleme auch bei anderen Sachen haben würde ich Dir da schon recht geben. Aber ein Paket gegen 995 die funktionieren lässt Zweifel aufkommen ...

'Ja var/tmp/portage liegt auf der besagten SSD.

Warum in den Speicher legen wenn der so schon nicht reicht das wird dadurch nicht schneller.

<Edit>

Auch läuft der Rechner beim arbeiten Super. Keine Hänger kein Zuckeln ... selbst wenn der nebenbei mit emerge -j8 Updates baut läuft der Desktop ohne das man was bemerkt. Hacken tut es nur wenn dann mit clang der Speicher knapp wird. Das wundert aber auch nicht sehr. Es gibt nichts lästigeres als Rechner die Hackel und beim arbeiten behindern. Das tut meiner aber auch nicht.

<Edit>

----------

## Max Steel

Du kein Problem. Du hast eine für dich brauchbare Lösung gefunden. Ich wollte nur noch einen weiteren Datenpunkt angeben der auf mögliche Probleme auf deiner Seite hinweisen könnte.

Für mich funktioniert die ganze Geschichte auf meinen ~amd64 System, auch mit 6GB auf dem Arbeits-Laptop ohne tmpfs oder mit 16GB RAM auf meinem Arbeits-PC. portagetmpfs braucht bei mir wegen chromium und qtwebengine zwar etwa 10G, nicht gerade wenig... aber das ist halt so. Ich lebe damit und es funktioniert für mich. Meine Maschinen swappen zwar unter Umständen aber das stört mich nur sekundär  :Wink:  Ich bin dazu übergegangen die Updates des Nachts laufen zu lassen und für chromium warte ich sogar bis zum Wochenende. respektive auf dem Heim-PCs läuft das während meinen Arbeitstagen/Nächten  :Wink: 

Ich denke wenn es weiteren Diskussionsbedarf gibt könnte man dashier in einen Diskussionsthread auslagern.

----------

## mike155

Selbst nach langem Nachdenken fällt mir kein Use Case dafür ein, alle Pakete mit "-ggdb" zu übersetzen. 

Normalerweise verwendet man "-ggdb" für die paar Pakete, mit denen man arbeitet - und konfiguriert das über package.env.

Und wenn man "-ggdb" aktiviert, will man sicherlich auch 

```
FEATURES="${FEATURES} splitdebug compressdebug -nostrip"
```

aktivieren, möglicherweise sogar

```
FEATURES="${FEATURES} installsources"
```

was aber beim TO laut make.conf nicht der Fall ist.

Also, für mich ergibt das alles überhaupt keinen Sinn!

----------

## Tyrus

 *alexander_ro wrote:*   

> Bei meinem letzten Versuch brauchte clang bei mir >4Stunden mit -j4. Ist halt ein älterer core-i7.
> 
> 

 

Also wie ich viel weiter oben schonmal geschrieben hatte - auf einem i3 mit 8GB Speicher und -j3 komm ich etwa 1:30 als Durchschnittszeit. Wobei die Zeiten wohl ansteigen (seit 2015)- der clang-10 hat dann 2:30h gebraucht grobe.

Also ich finde schon das man da mal schauen kann ob da nicht irgendwas verbessert werden kann. 

Also klar du willst den clang eh nicht mehr nutzen. Aber ich seh es so wie Max Steel geschrieben hat. Daher einfach als Ergänzung mal die Info noch ...

----------

## alexander_ro

@Max Steel

Klar ist immer meine Schuld ...  :Sad: 

Das habe ich bereits mit der Telekom durch die Hackelnde Standleitung kann ja nur die Schuld des Kunden sein Nach Monate langen Streits und Beschwerden bei der Bundesnetzagentur dem Vorstand und der Bundesregierung hat die Telekom dann doch mal den Arsch Bewegt und gesucht. Dann stellte sich heraus das die Hardware in der Vermittlunsstelle im Arsch war und der Router bei mir der aber unter Vollständiger Kontrolle der Telekom steht. Ich habe da keinerlei Zugang. Aber klar war meine Schuld das die Telekom interne Hardware kaputt ist ...  :Sad:  Ihr Argumentiert genauso wie die Telekom unter ignorieren sämtlicher Sachverhalte ... es ist mir ein Rätsel wieso man das tut.

Für mich stehen 995 Paket die Schnell und Sauber zu bauen sind gegen ein clang das abkackt. Klar ist mein Rechner kaputt ... zufällig halt immer wenn ich gerade clang baue ... gehts noch?

@mike155

Ich würde da beschränktes Vorstellungsvermögen vermuten ... z.B Fehlersuche oder das suchen was ein Parameter in der Software wirklich tut wenn die Doku mal wieder nichts taugt oder ich den Ami Slang nicht übersetzen kann. Sourcecode installiere ich wenn ich den brauche meist reichen aber die Symbole. Das geht sehr viel schneller als die Programm und libs neu zu bauen. Die anderen Optionen brauche nur die die so verwegen sind und Debug Symbole auf Prduktiv Maschinen installieren das ist aber eine Entwickler Rechner. Wie gesagt 995 Paket machen das auf dem Rechner locker vom Hocker ...  :Smile:  Ich kann mir auch nicht vorstellen wozu man einen Compiler braucht der sich nicht bauen lässt. Ihr sagt das ist Modern und Super ... Warum an Rechenleistung und Speichermodulen geizen China und die Atomenergie werden es schon richten ...  :Sad: 

@Tyrus

Also wenn meine nach eurer Meinung verbugte Hard und Software mit 995 Paketen kein Problem hat ... soll ich jetzt den Betatest für clang machen und deren Hausaufgaben damit ich einen Compiler bauen kann den ich nicht brauche. Habe ich das richtig verstanden ... eher Unwahrscheinlich das das passieren wird. Es ist nicht so das ich nicht Fehler suchen würde aber nur da wo es mir das Wert ist. Das Mozilla Zeug ist so klobig und Schwerfällig geworden das ich es schon lange los werden wollte aber immer zu Faul war eine Alternative zu suchen. Ist jetzt eine gute Gelegenheit. Wer sich vielleicht erinnert ich hatte vor nicht all zu langer Zeit ein Bluetooth Problem da habe ich auch selber im Sourcecode gesucht. Zufällig waren da die Debug Symbole auch sehr Hilfreich warum man sich das nicht Vorstellen kann weiß ich jetzt nicht. Mir sind aber dann die Entwickler mit einem Update zuvor gekommen. Nach dem Update war das Problem weg und ich habe das Suchen beendet.

<Edit>

Ich verstehe die Forumssoftware nicht die sagt immer wieder keine Beiträge verfügbar und macht meinen neuen dann zweimal rein. Hm ...

Bitte einen einfach übersehen ... danke  :Smile: 

</Edit>

----------

## Max Steel

 *alexander_ro wrote:*   

> @Max Steel
> 
> Klar ist immer meine Schuld ... 
> 
> Das habe ich bereits mit der Telekom durch die Hackelnde Standleitung kann ja nur die Schuld des Kunden sein Nach Monate langen Streits und Beschwerden bei der Bundesnetzagentur dem Vorstand und der Bundesregierung hat die Telekom dann doch mal den Arsch Bewegt und gesucht. Dann stellte sich heraus das die Hardware in der Vermittlunsstelle im Arsch war und der Router bei mir der aber unter Vollständiger Kontrolle der Telekom steht. Ich habe da keinerlei Zugang. Aber klar war meine Schuld das die Telekom interne Hardware kaputt ist ...  Ihr Argumentiert genauso wie die Telekom unter ignorieren sämtlicher Sachverhalte ... es ist mir ein Rätsel wieso man das tut.
> ...

 

Ich bin nicht die Telekom. Dein PC steht unter deiner Kontrolle, nicht meiner. Deine Konfiguration ist darauf. Ich wollte nur Datenpunkte geben die nichts anderes aussagen wie "works-for-me", oder "on-my-machine everythings fine".

Ich habe weder clang, noch llvm oder die binutils gemacht. Ich war auch nicht daran beteiligt.

Deine Router-Problematik tut mir leid für dich, kann ich aber nichts dafür: Immerhin, du kannst jederzeit zu deinem Anbieter gehen und sagen "Ich möchte einen eigenen Router installieren, geben Sie mir alle nötigen Informationen." Zumindest ist das mein letzter Stand über die Thematik, möglich dass diese veraltet sind.

Aber mach andere nicht verantwortlich für Dinge, mit denen diese nichts zu tun haben. In dieser Sache kann ich dir nur sagen, "works-on-my-machine"...

Es gibt viele Stolperfallen für die Erfahrungen die du machen musstest. Intel CPU Performance Einbußen durch die L1TF/Spectre/Meltdown/sonstwas Mitigationen zum Beispiel. Fehlende CPU Optimierungen (-march=native) zum kleinen Teil.

Zusätzlich zu erstellende Debugsymbolfiles (-ggdb) vielleicht.

Keine Ahnung, wirklich.

Das sind alles Dinge die nicht in meinem Wirkbereich sind und trotzdem dich betreffen können.

Ich übersetze zum test mal clang mit verschiedenen Einstellungen. Ich melde mich wieder wenn ich mehr weiß.

Sei aber gewarnt. Ich kann dein Setup nicht vollständig replizieren, also erwarte ich wenn überhaupt nur eine leichte verlängerung der Buildtime.

----------

## alexander_ro

Das ist mir schon klar das Du das alles nicht gemacht hast. Nur ist es immer so das erste was ich höre wenn ich irgendwo ein Technisches Problem habe ... das ist Deine Schuld ...  :Sad: 

Ganz ehrlich Spar Dir die Zeit Du hast sicher genug Ideen wie man die Sinnvoll verwenden kann. Wie ich schon seit längerem schreibe brauche ich clang nicht und alles was es als Zwang erfordert brauche ich auch nicht. Ist nicht meine Vorstellung von Freier Software wenn ich einen Zwangs C/C++ Compiler aufgedrückt bekomme. Wollte ich so etwas wäre ich bei Apple oder Microsoft.

Es geht auch nicht um Performance sondern darum das ich es mit 16GB RAM/SWAP nicht bauen kann. Wir haben ja eine Lösung gefunden wenn man die Debug Symbole aus macht geht es ja mit den 16GB das könnte man nun so hinfrickeln das nur der clang ohne gebaut wird. Da ich den nicht benutze ist mir das aber nicht den Aufwand Wert und Du solltest Dir noch mehr Aufwand dafür Sparen. Ist mir lieber wenn ich mal wieder ein für mich wichtiges Problem habe das Du die Zeit dann hast was zu schreiben. Trotzdem Danke für das Angebot und auch an alle anderen Danke auch wenn wir nicht immer gleicher Meinung sind ...  :Smile: 

----------

## mike155

Meiner Meinung nach sollte man als Nutzer von Open Source auch etwas zurückgeben. Eine gute Möglichkeit sind Bug Reports.

Es wäre schön, wenn wir einen Bug Report in der Gentoo- und in der GCC-Datenbank hätten:

- GCC braucht zum Übersetzen von Clang mit "-O2 -pipe" XXX Sekunden und XXX MB Hauptspeicher

- GCC braucht zum Übersetzen von Clang mit "-O2 -pipe -ggdb" YYY Sekunden und YYY MB Hauptspeicher

Dann könnten die Entwickler von GCC Compilers bzw. des Linkers sich das mal anschauen und vielleicht auch eine Lösung finden. Die GCC Entwickler haben ja schon einen Patch entwickelt, nur scheint der in diesem Fall nicht (ausreichend) zu funktionieren.

----------

## alexander_ro

Ich sehe jetzt nicht wirklich das das ein Problem vom gcc ist. Aber gut ich habe es nicht im Detail untersucht.

Da alles OpenSource (außer meinen) in Englisch gemacht wird kann ich da leider nicht Helfen. Fremdsprachen sind mir genau das ... Fremd.

Ich denke schon das ich was zurückgebe ich veröffentliche von mir Entwickelte Sachen wenn ich es darf. Geht leider nicht immer. Bei meinem Bluetooth Problem habe ich ja auch gesucht im Sourcecode wo das Problem liegen könnte. Die Doku ist nicht gerade gut und für jemanden der damit nichts zu tun hat ist das nicht einfach. Darum sind mir die Entwickler auch zuvorgekommen mit einer Lösung. Hätte ich vor denen die Lösung gefunden hätte ich die halt hier veröffentlicht. Bei den meisten Projekten sind auch Deutsch lesende Entwickler dabei die hätten das vielleicht ja hier auch gefunden. Wie gesagt Englisch ist nicht mein Ding wäre das anders würde ich auch im Englischen Teil des Forums schreiben.

<Edit>

Interessant ich konnte in dem Zeitraum den Firefox immer bauen.

</Edit>

----------

## mike155

 *alexander_ro wrote:*   

> Ich sehe jetzt nicht wirklich das das ein Problem vom gcc ist.

 

Ja! Weil Du die Links erst gar nicht gelesen hast, die ich gepostet habe.

Du warst in den letzten beiden Tagen wie im Rausch - und hast Dich völlig in kruden Theorien verbissen und auf alles und jeden geschimpft. Und hast überhaupt nicht mehr zugehört bzw. gelesen, was man Dir geschrieben hat.

----------

## Max Steel

Also bei mir ist folgender bauversuch:

time CFLAGS="-march=native -O2 -pipe -ggdb" CXXFLAGS="-march=native -O2 -pipe -ggdb" MAKEOPTS="-j4" ebuild /usr/portage/sys-devel/clang/clang-10.0.0.ebuild compile

mit einem "no space left on device" nach

```
real    67m14,370s

user    252m52,445s

sys     8m11,809s
```

ausgestiegen.

Der Fehler kam bei "step" [1362/1542]

Der Bau vorher hat funktioniert:

```
# emerge --info clang

Portage 2.3.103 (python 3.6.11-final-0, default/linux/amd64/17.1/desktop/plasma/systemd, gcc-10.1.0, glibc-2.31-r5, 5.5.10-gentoo x86_64)

=================================================================

                         System Settings

=================================================================

System uname: Linux-5.5.10-gentoo-x86_64-Intel-R-_Core-TM-_i5-3470S_CPU_@_2.90GHz-with-gentoo-2.7

KiB Mem:    16220888 total,   3653584 free

KiB Swap:   18874364 total,  15148540 free

Timestamp of repository gentoo: Mon, 06 Jul 2020 16:00:01 +0000

Head commit of repository gentoo: 0ad579e232bcc5b3c9a65d46b42d18d8f6badcd4

Head commit of repository genpi64: 61286e9fbfb27eee827bf023f5fb92d6ccce473f

sh bash 5.0_p17

ld GNU ld (Gentoo 2.34 p4) 2.34.0

app-shells/bash:          5.0_p17::gentoo

dev-java/java-config:     2.3.1::gentoo

dev-lang/perl:            5.30.3-r1::gentoo

dev-lang/python:          2.7.18::gentoo, 3.6.11-r1::gentoo, 3.7.8-r1::gentoo, 3.8.3-r1::gentoo, 3.9.0_beta4::gentoo

dev-util/cmake:           3.17.3::gentoo

dev-util/pkgconfig:       0.29.2::gentoo

sys-apps/baselayout:      2.7::gentoo

sys-apps/sandbox:         2.20::gentoo

sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo

sys-devel/automake:       1.13.4-r2::gentoo, 1.16.2::gentoo

sys-devel/binutils:       2.34-r1::gentoo

sys-devel/gcc:            10.1.0-r2::gentoo

sys-devel/gcc-config:     2.3.1::gentoo

sys-devel/libtool:        2.4.6-r6::gentoo

sys-devel/make:           4.3::gentoo

sys-kernel/linux-headers: 5.7::gentoo (virtual/os-headers)

sys-libs/glibc:           2.31-r5::gentoo

Repositories:

gentoo

    location: /usr/portage

    sync-type: rsync

    sync-uri: rsync://rsync.gentoo.org/gentoo-portage

    priority: -1000

    sync-rsync-extra-opts: 

    sync-rsync-verify-metamanifest: yes

    sync-rsync-verify-jobs: 1

    sync-rsync-verify-max-age: 24

ABI="amd64"

ABI_X86="64"

ACCEPT_KEYWORDS="amd64 ~amd64"

ACCEPT_LICENSE="* -@EULA"

ACCEPT_PROPERTIES="*"

ACCEPT_RESTRICT="*"

ADA_TARGET="gnat_2018"

ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident

usb-audio via82xx via82xx-modem ymfpci"

APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter

headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias"

ARCH="amd64"

AUTOCLEAN="yes"

BINPKG_COMPRESS="bzip2"

BOOTSTRAP_USE="unicode internal-glib pkg-config split-usr python_targets_python3_7 python_targets_python2_7 multilib systemd udev"

BROOT=""

CALLIGRA_FEATURES="karbon sheets words"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=native -O2 -pipe"

CFLAGS_amd64="-m64"

CFLAGS_x32="-mx32"

CFLAGS_x86="-m32"

CHOST="x86_64-pc-linux-gnu"

CHOST_amd64="x86_64-pc-linux-gnu"

CHOST_x32="x86_64-pc-linux-gnux32"

CHOST_x86="i686-pc-linux-gnu"

CLEAN_DELAY="5"

COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog"

COLLISION_IGNORE="/lib/modules/*"

COLORTERM="truecolor"

CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.4/ext-active/ /etc/php/cgi-php7.4/ext-active/ /etc/php/cli-php7.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3"

CXXFLAGS="-march=native -O2 -pipe"

DEFAULT_ABI="amd64"

DISTDIR="/usr/portage/distfiles"

EDITOR="/usr/bin/vi"

ELIBC="glibc"

EMERGE_DEFAULT_OPTS="-tv --with-bdeps=y --keep-going --quiet-build=y"

EMERGE_WARNING_DELAY="10"

ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT

XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"

EPREFIX=""

EROOT="/"

ESYSROOT="/"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"

FETCHCOMMAND="wget -t 3 -T 60 --passive-ftp -O "${DISTDIR}/${FILE}" "${URI}""

FETCHCOMMAND_RSYNC="rsync -LtvP "${URI}" "${DISTDIR}/${FILE}""

FETCHCOMMAND_SFTP="bash -c "x=\${2#sftp://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; eval \"declare -a ssh_opts=(\${3})\" ; exec sftp \${port:+-P \${port}} \"\${ssh_opts[@]}\" \"\${host}:/\${x#*/}\" \"\$1\"" sftp "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""

FETCHCOMMAND_SSH="bash -c "x=\${2#ssh://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; exec rsync --rsh=\"ssh \${port:+-p\${port}} \${3}\" -avP \"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""

FFLAGS="-O2 -pipe"

GCC_SPECS=""

GENTOO_MIRRORS="http://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://tux.rainside.sk/gentoo/ rsync://ftp.snt.utwente.nl/gentoo"

GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx"

GRUB_PLATFORMS=""

GSETTINGS_BACKEND="dconf"

HOME="/root"

INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/10.1.0/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.34/info:/usr/share/info"

INPUT_DEVICES="libinput"

IUSE_IMPLICIT="abi_x86_64 prefix prefix-guest prefix-stack"

KERNEL="linux"

L10N="de"

LANG="de_DE.utf8"

LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text"

LC_COLLATE="de_DE.utf8"

LC_CTYPE="de_DE.utf8"

LC_MESSAGES="C"

LC_NUMERIC="de_DE.utf8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LDFLAGS_amd64="-m elf_x86_64"

LDFLAGS_x32="-m elf32_x86_64"

LDFLAGS_x86="-m elf_i386"

LESS="-R -M --shift 5"

LESSOPEN="|lesspipe %s"

LIBDIR_amd64="lib64"

LIBDIR_x32="libx32"

LIBDIR_x86="lib"

LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer"

LINGUAS="de"

LOGNAME="root"

LS_COLORS="rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:

ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:

*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:

*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:

*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:

*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:

*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:

*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:

*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.cfg=00;32:*.conf=00;32:*.diff=00;32:*.doc=00;32:*.ini=00;32:*.log=00;32:*.patch=00;32:*.pdf=00;32:*.ps=00;32:*.tex=00;32:*.txt=00;32:

*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:

*.opus=00;36:*.spx=00;36:*.xspf=00;36:"

MAKEOPTS="-j4"

MANPAGER="manpager"

MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/10.1.0/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.34/man:/etc/java-config-2/current-system-vm/man/:

/usr/lib64/php7.4/man/:/usr/local/share/man:/usr/share/man:/usr/lib/llvm/10/share/man"

MOZ_GMP_PATH="/usr/lib64/nsbrowser/plugins/gmp-gmpopenh264/system-installed"

MULTILIB_ABIS="amd64 x86"

MULTILIB_STRICT_DENY="64-bit.*shared object"

MULTILIB_STRICT_DIRS="/lib32 /lib /usr/lib32 /usr/lib /usr/kde/*/lib32 /usr/kde/*/lib /usr/qt/*/lib32 /usr/qt/*/lib /usr/X11R6/lib32 /usr/X11R6/lib"

MULTILIB_STRICT_EXEMPT="(perl5|gcc|gcc-lib|binutils|eclipse-3|debug|portage|udev|systemd|clang|python-exec|llvm)"

OFFICE_IMPLEMENTATION="libreoffice"

OPENCL_PROFILE="beignet"

OPENGL_PROFILE="xorg-x11"

PAGER="/usr/bin/less"

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/10/bin"

PHP_TARGETS="php7-2"

PKGDIR="/usr/portage/packages"

PORTAGE_ARCHLIST="alpha amd64 amd64-linux arm arm-linux arm64 arm64-linux hppa ia64 m68k m68k-mint mips ppc ppc-aix ppc-macos ppc64 ppc64-linux

riscv s390 sparc sparc-solaris sparc64-solaris x64-cygwin x64-macos x64-solaris x64-winnt x86 x86-cygwin x86-linux x86-macos x86-solaris x86-winnt"

PORTAGE_BIN_PATH="/usr/lib/portage/python3.6"

PORTAGE_COMPRESS_EXCLUDE_SUFFIXES="css gif htm[l]? jp[e]?g js pdf png"

PORTAGE_CONFIGROOT="/"

PORTAGE_DEBUG="0"

PORTAGE_DEPCACHEDIR="/var/cache/edb/dep"

PORTAGE_ELOG_CLASSES="log warn error"

PORTAGE_ELOG_MAILFROM="portage@localhost"

PORTAGE_ELOG_MAILSUBJECT="[portage] ebuild log for ${PACKAGE} on ${HOST}"

PORTAGE_ELOG_MAILURI="root"

PORTAGE_ELOG_SYSTEM="save_summary:log,warn,error,qa echo"

PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS="5"

PORTAGE_FETCH_RESUME_MIN_SIZE="350K"

PORTAGE_GID="250"

PORTAGE_GPG_SIGNING_COMMAND="gpg --sign --digest-algo SHA256 --clearsign --yes --default-key "${PORTAGE_GPG_KEY}" --homedir "${PORTAGE_GPG_DIR}"

"${FILE}""

PORTAGE_INST_GID="0"

PORTAGE_INST_UID="0"

PORTAGE_INTERNAL_CALLER="1"

PORTAGE_LOGDIR_CLEAN="find "${PORTAGE_LOGDIR}" -type f ! -name "summary.log*" -mtime +7 -delete"

PORTAGE_OVERRIDE_EPREFIX=""

PORTAGE_PYM_PATH="/usr/lib64/python3.6/site-packages"

PORTAGE_PYTHONPATH="/usr/lib64/python3.6/site-packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"

PORTAGE_RSYNC_RETRIES="-1"

PORTAGE_SYNC_STALE="30"

PORTAGE_TMPDIR="/var/tmp"

PORTAGE_VERBOSE="1"

PORTAGE_WORKDIR_MODE="0700"

PORTAGE_XATTR_EXCLUDE="btrfs.* security.evm security.ima        security.selinux system.nfs4_acl user.apache_handler    user.Beagle.* user.dublincore.* user.mime_encoding user.xdg.*"

POSTGRES_TARGETS="postgres10 postgres11"

PRELINK_PATH_MASK="/opt/eagle"

PROFILE_ONLY_VARIABLES="ARCH ELIBC IUSE_IMPLICIT KERNEL USERLAND USE_EXPAND_IMPLICIT USE_EXPAND_UNPREFIXED USE_EXPAND_VALUES_ARCH

USE_EXPAND_VALUES_ELIBC USE_EXPAND_VALUES_KERNEL USE_EXPAND_VALUES_USERLAND"

PWD="/root"

PYTHONDONTWRITEBYTECODE="1"

PYTHON_SINGLE_TARGET="python3_7"

PYTHON_TARGETS="python2_7 python3_7 python3_6"

QEMU_SOFTMMU_TARGETS="x86_64 aarch64 arm armeb"

QEMU_USER_TARGETS="aarch64 aarch64_be arm armeb"

QT_GRAPHICSSYSTEM="raster"

RESUMECOMMAND="wget -c -t 3 -T 60 --passive-ftp -O "${DISTDIR}/${FILE}" "${URI}""

RESUMECOMMAND_RSYNC="rsync -LtvP "${URI}" "${DISTDIR}/${FILE}""

RESUMECOMMAND_SSH="bash -c "x=\${2#ssh://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ;

exec rsync --rsh=\"ssh \${port:+-p\${port}} \${3}\" -avP \"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}""

ROOT="/"

ROOTPATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/10/bin:/opt/eagle/bin"

RPMDIR="/var/cache/rpm"

RUBY_TARGETS="ruby26 ruby27"

SHELL="/bin/bash"

SHLVL="1"

SYMLINK_LIB="no"

SYSROOT="/"

TERM="xterm-256color"

TMP="/tmp/.private/root"

TMPDIR="/tmp/.private/root"

TWISTED_DISABLE_WRITING_OF_PLUGIN_CACHE="1"

UNINSTALL_IGNORE="/lib/modules/* /var/run /var/lock"

USE="7z X a52 aac aalib acl acpi activities addns ads aio alsa amd64 apm bash-completion berkdb bluetooth bluray branding bzip2 cairo caps cdda cddb cdio cdparanoia

cdr checksum clang cli client crypt cryptsetup cups dbus declarative dhcp-tools dhcpcd dri dts dvb dvd dvdr emboss encode ethernet evdev exif flac foomatic foomaticdb fortran

fuse fusefs g711 g722 g7221 g726 gdbm ghostscript gif gles gpm gtk gtk3 http2 i18n iconv icu ipv6 jpeg jumbo-build kde kdenlive kipi kwallet lcms ldap ldap-bind ldap-sasl

legacy-systray libass libnotify libtirpc libusb logrotate luks lvm lzma lzo mad mktemp mng modplug mp3 mp4 mpeg mtp multilib ncurses nls nptl nss ntfs ntlm ogg opengl

openmp openssl pam pango pcre pdf perl phonon pim plasma png policykit ppds projectm pulseaudio python qml qt4 qt5 rdesktop rdp readline rtc samba sdl seccomp

semantic-desktop sip slang spamassassin spell split-usr ssh ssh-agent ssl startup-notification svg systemd tcpd tiff truetype udev udisks unicode upower usb user-session vaapi

vnc voip vorbis vte wav wayland webdav webgl widevine widgets wxwidgets x264 xattr xcb xinerama xml xrandr xscreensaver xv xvid xz zip zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 

intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias 

authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock 

deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status 

unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 

garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt 

ublox ubx" INPUT_DEVICES="libinput" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" 

POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7 python3_6" QEMU_SOFTMMU_TARGETS="x86_64 aarch64 arm armeb" QEMU_USER_TARGETS="aarch64 aarch64_be arm armeb" RUBY_TARGETS="ruby26 ruby27" 

USERLAND="GNU" VIDEO_CARDS="intel i915 i965 fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee

 tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

USER="root"

USERLAND="GNU"

USE_EXPAND="ABI_MIPS ABI_PPC ABI_RISCV ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES

 CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC ENLIGHTENMENT_MODULES FFTOOLS

 GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LIRC_DEVICES LLVM_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION 

OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS 

QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS 

VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS"

USE_EXPAND_HIDDEN="ABI_MIPS ABI_PPC ABI_RISCV ABI_S390 CPU_FLAGS_ARM CPU_FLAGS_PPC ELIBC KERNEL USERLAND"

USE_EXPAND_IMPLICIT="ARCH ELIBC KERNEL USERLAND"

USE_EXPAND_UNPREFIXED="ARCH"

USE_EXPAND_VALUES_ARCH="alpha amd64 amd64-fbsd amd64-linux arm arm64 hppa ia64 m68k m68k-mint mips ppc ppc64 ppc64-linux ppc-aix ppc-macos riscv s390

 sparc sparc64-solaris sparc-solaris x64-cygwin x64-macos x64-solaris x64-winnt x86 x86-cygwin x86-fbsd x86-linux x86-macos x86-solaris x86-winnt"

USE_EXPAND_VALUES_ELIBC="AIX bionic Cygwin Darwin DragonFly FreeBSD glibc HPUX Interix mingw mintlib musl NetBSD OpenBSD SunOS uclibc Winnt"

USE_EXPAND_VALUES_KERNEL="AIX Darwin FreeBSD freemint HPUX linux NetBSD OpenBSD SunOS Winnt"

USE_EXPAND_VALUES_USERLAND="BSD GNU"

USE_ORDER="env:pkg:conf:defaults:pkginternal:features:repo:env.d"

VBOX_APP_HOME="/usr/lib64/virtualbox"

VIDEO_CARDS="intel i915 i965 fbdev"

XDG_CONFIG_DIRS="/etc/xdg"

XDG_DATA_DIRS="/usr/local/share:/usr/share"

XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude 

chaos account"

=================================================================

                        Package Settings

=================================================================

sys-devel/clang-10.0.0::gentoo was built with the following:

USE="static-analyzer xml -debug -default-compiler-rt -default-libcxx -doc -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC 

-ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8"

FEATURES="usersandbox sandbox sfperms pid-sandbox binpkg-logs ebuild-locks distlocks protect-owned assume-digests network-sandbox ipc-sandbox binpkg-dostrip 

userfetch xattr merge-sync parallel-fetch unmerge-orphans usersync config-protect-if-modified unknown-features-warn qa-unresolved-soname-deps userpriv news 

preserve-libs multilib-strict binpkg-docompress fixlafiles unmerge-logs strict"

```

```
# genlop -ti clang

[...]

     Wed Jul  1 23:34:07 2020 >>> sys-devel/clang-10.0.0

       merge time: 53 minutes and 49 seconds.

   Total builds: 18

   Global build time: 8 hours, 55 minutes and 22 seconds.

   Average merge time: 29 minutes and 44 seconds.

   Info about currently installed ebuild:

   * sys-devel/clang-10.0.0

   Install date: Wed Jul  1 23:34:07 2020

   USE=""

   CFLAGS="-march=native -O2 -pipe"   CXXFLAGS="-march=native -O2 -pipe"   LDFLAGS="-Wl,-O1 -Wl,--as-needed"

```

Aber okay. Schöne Woche dir noch.

----------

## alexander_ro

Und woher wusste ich dann das der eine gcc Bug Uralt und beide nicht meiner Version waren wenn ich es nicht gelesen habe. Beweise siehe meine Antworten oben dazu. Ich bin mir nicht sicher wer da gerade nicht liest oder im Rausch ist.

Krude Theorien wenn 995 Pakete mit dem gcc mit meinen Parameter schnell und innerhalb der 16 GB bauen ... ja?

----------

## mike155

@Max Steel: ich habe auch gerade angefangen, das nachzustellen. Dauert leider alles recht lange. Ich werde die Ergebnisse posten. 

Vielleicht können wir herausfinden, was das Problem ist - und dann einen Bug Report schreiben.

----------

## Tyrus

Also ich habe das jetzt auch mal getestet mit -ggdb und mit USE=debug und ausserdem -j3

Die 32-bit Version (ich weiss nicht nötig - aber hab ich mich noch nicht drum gekümmert ... *grins*) baut sauber durch.

Die 64-bit Version bricht ab. Schritt bei mir ist:

```

[1350/1547] : && /usr/bin/cmake -E remove lib64/libclangTidyUtils.a && /usr/bin/x86_64-pc-linux-gnu-ar Dqc lib64/libclangTidyUtils.a  tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/ASTUtils.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/DeclRefExprUtils.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/ExceptionAnalyzer.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/ExprSequence.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/FixItHintUtils.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/HeaderFileExtensionsUtils.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/HeaderGuard.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/IncludeInserter.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/IncludeSorter.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/LexerUtils.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/NamespaceAliaser.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/OptionsUtils.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/TransformerClangTidyCheck.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/TypeTraits.cpp.o tools/extra/clang-tidy/utils/CMakeFiles/obj.clangTidyUtils.dir/UsingInserter.cpp.o && /usr/bin/x86_64-pc-linux-gnu-ranlib -D lib64/libclangTidyUtils.a && :

```

Das eigentlich Kommando das fehlschlägt ist:

```

/usr/bin/x86_64-pc-linux-gnu-ranlib -D lib64/libclangTidyUtils.a

/usr/bin/x86_64-pc-linux-gnu-ranlib: lib64/libclangTidyUtils.a: Auf dem Gerät ist kein Speicherplatz mehr verfügbar

```

Die Ursache ist btw nicht der Arbeitsspeicher sondern die Festplatte. "df" zeigt

```

df

Dateisystem                                    1K-Blöcke    Benutzt Verfügbar Verw% Eingehängt auf

[...]

/dev/mapper/LOCAL-VAR--TMP--PORTAGE             22224896   20192708     46588  100% /var/tmp/portage

[...]

```

*jetzt mal grinsen muss*

/var/tmp/portage hat bei mir 19 GB. 

-------------

Ich schaue jetzt mal ob ich da etwas mehr Speicher drauf bekomme und lass es danach weiter bauen ...  :Wink: 

----------

## firefly

 *Tyrus wrote:*   

> 
> 
> Die Ursache ist btw nicht der Arbeitsspeicher sondern die Festplatte. "df" zeigt
> 
> ```
> ...

 

Was auch verständlich ist denn die debug informationen benötigten auch platz und das meist deutlich mehr als für den eigendlich übersetzten code.

Wie im bugreport auf bugs.gentoo.org, dessen link mike155 gepostet hat, kann der benötigte plattenplatz 3-5 fache dem entsprechen als einem build ohne debug informationen.

Und ähnlich gilt es auch für den RAM verbrauch wenn dann die angewachsenen object files zu einer library oder executable vom linker zusammengebaut werden.

Im Beispiel von dem bugreport ist das ca das 5 fache am benötigten RAM.

Und der RAM bedarf steigt natürlich wenn mehrere dieser linker aktionen parallel laufen.

Hier mal ein paar konkrete sehr einfache beispiele für die datei größen der objectfiles

debug.cpp

```
int main(int argc, char** argv)

{

    return 0;

}
```

```
$ g++ -march=native -c -o debug.o debug.cpp

$ g++ -march=native -c -ggdb -o debug_ggdb.o debug.cpp
```

und hier die dateigrößen (bytes):

 *Quote:*   

> debug.o 1216
> 
> debug_ggdb.o 3040

 

Die Dateigröße mit debug symbolen ist ~2.5x so groß

```
$ g++ -march=native -O2 -c -o debug.o debug.cpp

$ g++ -march=native -O2 -c -ggdb -o debug_ggdb.o debug.cpp
```

 *Quote:*   

> debug.o 1304
> 
> debug_ggdb.o 3376

 

Die Dateigröße mit debug symbolen ist ~2.5x so groß

debug.cpp

```
#include <iostream>

int main(int argc, char** argv)

{

    std::cout<<"hello world\n";

    return 0;

}
```

```
$ g++ -march=native -c -o debug.o debug.cpp

$ g++ -march=native -c -ggdb -o debug_ggdb.o debug.cpp
```

und hier die dateigrößen (bytes):

 *Quote:*   

> debug.o 2584
> 
> debug_ggdb.o 26320

 

Die Dateigröße mit debug symbolen ist ~10.2x so groß

```
$ g++ -march=native -O2 -c -o debug.o debug.cpp

$ g++ -march=native -O2 -c -ggdb -o debug_ggdb.o debug.cpp
```

 *Quote:*   

> debug.o 2464
> 
> debug_ggdb.o 28504

 

Die Dateigröße mit debug symbolen ist ~11.5x so groß

Das ganze lieft mit gcc 9.3.0 auf einem Ryzen 9 3900X

----------

## Tyrus

So ich habs jetzt fertig gebaut. Es geht also.

Anforderungen:

```

pydf

Filesystem                              Size  Used Avail Use%                      Mounted on                                   

[...]

/dev/INTENSO--EXTERN/TEST               471G   32G  436G  6.8 [#.................] /var/tmp/portage     

[...]

```

Also 32G braucht das mit Debugsymbolen.

Was den Swap angeht - ich hab 16 GiB eingerichtet. Und es ist grade so durchgebaut worden. Ich hatte dafür extra das Desktop abschalten müssen. Mit Desktop hängt es sich ganz am Ende auf.

Die letzten etwa 30 Steps reizen dann wirklich alles aus. Ich hatte nur noch top nebenher laufen. Es kam trotzdem zu Hängern - sobald eine Refresh wieder da war zeigte top dann als Höchstwert fast 16 GiB Swap-Last an. 

Aber es geht ... *schmunzel*

----------

## mike155

Nach mehreren Fehlversuchen habe ich es auch noch hinbekommen.  :Smile: 

Ich hatte eine Maschine mit 32 GB RAM (kein Swap) und /var/tmp/portage auf einer Festplatte/SSD (kein tmpfs). Dann klappt es sowohl mit MAKEOPTS="-j1", als auch mit "-j4".

Ich habe folgende Szenarien getestet:

Szenario A: CFLAGS=CXXFLAGS="-O2 -pipe"

Szenario B: CFLAGS=CXXFLAGS="-O2 -pipe -ggdb"

Randbedingungen: 

Compiler: Gentoo GCC stable 9.3.0 64 Bit

Übersetztes Paket: sys-devel/clang stable 10.0.0

Kommando: time ebuild /var/db/repos/gentoo/sys-devel/clang/clang-10.0.0.ebuild compile

MAKEOPTS="-j1"

Ein paar Messwerte:

```
+---------------------------------+------------+------------+--------+

|                                 | Szenario A | Szenario B | Faktor |

+---------------------------------+------------+------------+--------+

| Größe /var/tmp/portage          |    1.4 GB  |     24 GB  |   17   |

| Größe bin/clangd                |     14 MB  |   1370 MB  |   98   |

| Größe lib64/libclang.so.10      |     53 MB  |   2651 MB  |   50   |

+---------------------------------+------------+------------+--------+

```

Das sind schon große Unterschiede! @firefly hat ja schon gezeigt, dass Debug-Informationen viel Platz benötigen. Aber ein Faktor 50 oder 100? 

Jetzt stellen sich folgende Fragen:

Ist das alles in Ordnung? Oder haben wir es mit einem Bug zu tun?

Falls es ein Bug ist: ist er nur im Gentoo GCC? Oder auch im normalen GCC? In welchen Versionen?

----------

## franzf

Zum Verifizieren, ob es wirklich ein gcc-bug ist, könnte man clang noch mit clang übersetzen und den Speicherverbrauch messen.

```
cat /etc/portage/env/clang.conf

CC=clang

CXX=clang++
```

Und in /etc/portage/package.env dann

```
sys-devel/clang clang.conf
```

Während dem Übersetzen kann man mit top verifizieren, dass wirklich clang verwendet wird und nicht gcc.

----------

## firefly

 *mike155 wrote:*   

> Ein paar Messwerte:
> 
> ```
> +---------------------------------+------------+------------+--------+
> 
> ...

 

Hast du eventuell das feature splitdebug aktiv? Wobei ich nicht weis ob dieses feature bei einem ebuild <path> compile schon genutzt wird nicht erst bei "merge".

Falls doch schon in dieser Phase das Feature aktiv ist, dann sollte es *.debug (z.b. libclang.so.10.debug) files geben. Und falls ja müsste man die Dateigröße dieser Datei für das Szenario B dazurechnen.

----------

## alexander_ro

Der Unterschied in der Bauzeit liegt vielleicht zum Teil an dem Umstand das ich wie oben auch geschrieben clang und alles was dazu gehört entfernt hatte. Ihr habt vermutlich einen rebuild gemacht.

Euch ist schon klar das man derartige Problem nur hat wenn man gigantische Monolithen zusammen linkt?

Vielleicht solltet ihr mal ein gutes Buch über Software Design lesen und da besonders die Teile warum Monolithen unhübsch sind?

Ich möchte nochmal auf die weitläufig ignorierten Sachverhalte hinweisen. Wie oben steht habe ich von -j8 auf -j4 reduziert, 6GB RAM frei und 10GB SWAP. Alle 995 Pakete (clang ist nicht das einzige große) wurden mit -j8 und Debugsymbolen gebaut ... Fehler frei. Also alle außer clang kommen damit Problemlos klar. Ich kann ja verstehen das man sein Lieblingsprojekt gerne von jeder Schuld rein waschen will ... aber könnte es sein das ihr ein bisschen Übertreibt ...

----------

## Max Steel

 *alexander_ro wrote:*   

> Der Unterschied in der Bauzeit liegt vielleicht zum Teil an dem Umstand das ich wie oben auch geschrieben clang und alles was dazu gehört entfernt hatte. Ihr habt vermutlich einen rebuild gemacht.

 

Deswegen habe ich lieber kleine Häppchen wie mit dem ebuild (oder emerge -1 rebuilds) und vertraue grundsätzlich mehr darauf was genlop sagt (oder eben time ebuild)

Dann bekomme ich die Buildtime nur dieses einen Paketes und nicht dem gesamten Aufruf von emerge welcher von System zu System unterschiedlich ist.

 *alexander_ro wrote:*   

> Vielleicht solltet ihr mal ein gutes Buch über Software Design lesen und da besonders die Teile warum Monolithen unhübsch sind?

 

Der Linux-Kernel ist das beste Beispiel dafür dass ein Monolith nicht zwangsweiße zur Katastrophe mutiert. Aber vll willst du lieber zu einem dieser moderneren Hybridkernel wie Windows NT zurückgreifen?

 *alexander_ro wrote:*   

> Ich möchte nochmal auf die weitläufig ignorierten Sachverhalte hinweisen. Wie oben steht habe ich von -j8 auf -j4 reduziert, 6GB RAM frei und 10GB SWAP. Alle 995 Pakete (clang ist nicht das einzige große) wurden mit -j8 und Debugsymbolen gebaut ... Fehler frei. Also alle außer clang kommen damit Problemlos klar. Ich kann ja verstehen das man sein Lieblingsprojekt gerne von jeder Schuld rein waschen will ... aber könnte es sein das ihr ein bisschen Übertreibt ...

 

Und ich möchte nochmal darauf hinweißen dass die Debug-Symbole ein Grund dafür sind dass es so lange dauert, solviel Platz verbraucht und bei manchen nicht zum Abschluss führen. Du scheinst für deine Zwecke die Debug-Symbole auf clang zu benötigen (einem Projekt das nur zur Buildtime von firefox überhaupt anwendung findet wenn ich mich recht entsinne) und das ist ja okay. Hindert dich keiner daran, daran festzuhalten obwohl es aus meiner Sicht absolut keinen Grund gibt. Aber ist shcon in Ordnung. Wir wollen hier aber versuchen die ganze Umgebung zu verbessern, vll identifizieren wir ein Problem bei GCC, vll bei clang. Oder garnichts. Wenn wir da Zeit reinstecken wollen hast du erstmal Sendepause. Mag sein dass es für dich sinnlos vergeudete Zeit ist, aber wir tun das nicht mehr wegen dir.

Wir haben dir unsere Meinung zu deinem Problem mitgeteilt. Offensichtlich ist bei dem derzeitigen Kenntnissstand deine Konfiguration eine Wahl die das PRoblem erzeugt. Du möchtest daran festhalten.

 *mike155 wrote:*   

> 2. Falls es ein Bug ist: ist er nur im Gentoo GCC? Oder auch im normalen GCC? In welchen Versionen?

 

gcc hat ja das Flag vanilla mit dem alle Gentoo-spezifischen PAtches deaktiviert werden, soweit ich noch weiß.

----------

## alexander_ro

Der Kernel ist Lichtjahre von einem Monolithen entfernt seit der Einführung der Kernel-Module. Der Vorwurf an den Kernel ist so alt wie er heute falsch ist.

Man kann zwar den Kernel als Monolithen bauen ich bin mir aber nicht sicher ob es überhaupt noch möglich ist die Module komplett abzuschalten. Monolithen bauen ist keine Katastrophe verursacht aber große Probleme wie z.B. "out of mem" und erschwert die Entwicklungsarbeit. Ich würde mal vermuten wenn man beim Kernel die Module ganz abschaltet das man beim bauen ähnliche Probleme hat. Die Kernel Entwickler haben das schon vor Jahrzehnten erkannt und eine Lösung eingebaut.

Wenn man sich die Liste der Interessierten Firmen anschaut die clang Finanzieren ist klar warum denen Ressourcen Verbrauch Wurscht ist. Die habe alle Fette Rechenzentren ... darfs auch ein Terabyte mehr sein ... fragt da vermutlich der Admin wenn er die Entwicklungsumgebung einrichtet.

Ich meinte nicht was ihr mit eurer Zeit macht. Das bisherige Geschehen lies mich nicht erkennen das man in Betracht zieht das clang ein Problem haben könnte. Dazu meinte ich es ist übertrieben unbedingt nur einen Fehler beim gcc sehen zu wollen. Ihr dürft alle gerne tun was ihr wollt. Auch oben die Bemerkung das ihr eure Zeit sparen solltet war nur so gemeint das ihr das nicht wegen mir weiter suchen solltet. Ich will euch sicher nicht vorschreiben was ihr tut.

Die Pakete Bauzeit wird egal mit was gemessen von System zu System unterschiedlich sein.

----------

## firefly

Wieso soll das ein Problem bei clang sein?

Du stellts hier nur Behauptungen auf aber ohne sinvolle begründung.

Der Unterschied zwischen clang 9 und clang 10 ist  unter anderem der zusätzliche/erweiterte support des C++ standards C++20.

Da gibt es einige neue Sprach features für welche unter anderem der Source code parser und der code generator des compilers erweitert werden muss.

=> Clang 10 hat mehr neue features als clang 9 wodurch sich natürlich auch die größe der Binaries und im falle eines debug builds mit debug symbolen die größe der Debug informationen steigt.

Und clang ist keines wegs monolitisch wie du immer wieder andeutest.

z.b. bei clang 9 besteht die installation aus 100-140 .so files (genaue zahlen habe ich aktuell nicht zur hand da nicht am heimischen Rechner)

Und ich denke deine Definition unterscheidet sich stark zu der definfition welche die meisten anderen Entwickler nutzen.

Denn der linux kernel ist monolitsch obwohl er kernel module hat. Denn die definition für einen monolitischen Kernel ist wie folgt:

https://stackoverflow.com/questions/1806585/why-is-linux-called-a-monolithic-kernel

 *Quote:*   

> A monolithic kernel is a kernel where all services (file system, VFS, device drivers, etc) as well as core functionality (scheduling, memory allocation, etc.) are a tight knit group sharing the same space. This directly opposes a microkernel.

 

Oder auch hier wird der linux kernel als monolitisch bezeichnet:

https://www.howtogeek.com/howto/31632/what-is-the-linux-kernel-and-what-does-it-do/

----------

## Tyrus

Hallo firefly.

Um deine Zahlen zu clang-9.0.1 zu bestätigen - ich habe hier noch die 9er Version und daneben die 10er von clang (noch ist nicht alles auf clang:10 umgestellt). (Am Rande ich habe jetzt auch nur noch die 64-bit Version ...)

```

equery f sys-devel/clang-9.0.1 | grep '\.so' | wc -l

136

```

```

ls -l $(equery f sys-devel/clang-9.0.1 | grep '\.so')

lrwxrwxrwx 1 root root       17  9. Jul 04:03 /usr/lib/llvm/9/lib64/libclang-cpp.so -> libclang-cpp.so.9

-rwxr-xr-x 1 root root 60462000  9. Jul 03:32 /usr/lib/llvm/9/lib64/libclang-cpp.so.9

lrwxrwxrwx 1 root root       13  9. Jul 04:03 /usr/lib/llvm/9/lib64/libclang.so -> libclang.so.9

-rwxr-xr-x 1 root root   782312  9. Jul 04:02 /usr/lib/llvm/9/lib64/libclang.so.9

[...]

```

Jetzt aber:

```

equery f sys-devel/clang-10.0.0 | grep '\.so' | wc -l

4

```

Konkreter es gibt nur noch:

```

ls -l $(equery f sys-devel/clang-10.0.0 | grep '\.so')

lrwxrwxrwx 1 root root       18  9. Jul 02:52 /usr/lib/llvm/10/lib64/libclang-cpp.so -> libclang-cpp.so.10

-rwxr-xr-x 1 root root 65812440  9. Jul 02:13 /usr/lib/llvm/10/lib64/libclang-cpp.so.10

lrwxrwxrwx 1 root root       14  9. Jul 02:52 /usr/lib/llvm/10/lib64/libclang.so -> libclang.so.10

-rwxr-xr-x 1 root root 53782288  9. Jul 02:52 /usr/lib/llvm/10/lib64/libclang.so.10

```

Die Ursache - darauf hatte mich franzf heute vormittag schon hingewiesen - ich bin mal so frei und schreib das hier jetzt einfach - danke für den Hinweis @franzf: 

https://github.com/gentoo/gentoo/blob/master/sys-devel/clang/clang-9.0.1.ebuild#L105

https://github.com/gentoo/gentoo/blob/master/sys-devel/clang/clang-10.0.0.ebuild#L174

Warum der EBuild da so "verändert" wurde wäre jetzt zu fragen. Es liegt also nicht bei den Entwicklern von clang das Version 10 jetzt "monolitischer" gebaut wird als vorher ... clang bietet diese Möglichkeit nur an ...

@franzf:

Einen Test clang mal mit clang zu bauen versuch ich später. Das reizt mich auch was da rauskommt ... *grins*

----------

## alexander_ro

 *Quote:*   

> 
> 
> Du stellts hier nur Behauptungen auf aber ohne sinvolle begründung.
> 
> 

 

Nicht ganz. Ich habe das Statistisch Belegt 995 + meine Projekte zu 1 kein Schlechtes Statistisches Argument.

Du sagst ja selbst die haben da viel neu gebaut. Wäre nicht das erste mal das neu gebaute Software nicht ganz tut was sie soll.

Jetzt will er Haare spalten ... Meister Tannenbaum mochte das auch immer.

Wir reden hier aber nicht von der Runtime sondern Compiletime. Kernel und Module sind vollständig getrennte Übersetzungseinheiten. Das einzige was alle haben ist die Schnittstelle.

Fakt ist der Kernel Compiliert locker vom Hocker und clang nicht ... klar nur ein kleiner Unterschied aber wichtig.

----------

## mike155

Ich habe clang 10 auch noch mit Gentoo GCC 7.5.0 übersetzt.

Ergebnis: Gentoo GCC 9.3.0 produziert um 50% größere Dateien als Gentoo GCC 7.5.0:

```
+---------------------------------+------------+------------+------------+

|                                 | Szenario A | Szenario B | Szenario C |

+---------------------------------+------------+------------+------------+

| Compiler                        |  GCC 9.3   |  GCC 9.3   |  GCC 7.5   |

| Flags (neben -O2 und -pipe)     |            |  -ggdb     |  -ggdb     |

+---------------------------------+------------+------------+------------+

| Größe /var/tmp/portage          |    1.4 GB  |     24 GB  |     17 GB  |

| Größe bin/clangd                |     14 MB  |   1370 MB  |    947 MB  |

| Größe lib64/libclang.so.10      |     53 MB  |   2651 MB  |   1826 MB  |

+---------------------------------+------------+------------+------------+

```

----------

## firefly

 *alexander_ro wrote:*   

>  *Quote:*   
> 
> Du stellts hier nur Behauptungen auf aber ohne sinvolle begründung.
> 
>  
> ...

 

Nur da hast du einen denkfehler. Von den 995 Paketen haben 90-99% nicht die gleiche größe der code basis wie clang bzw. sind in C geschrieben statt C++ was hier auch nochmal einen unterschied machen kann.

Und ein teil deiner 995 Pakete sind nicht mal in C oder C++ geschrieben sondern in perl, python oder einer anderen script sprache...

Du begründest also deine Vermutung mit einer Statistik bei der ein großteil der Pakete gar nicht die kriterien erfüllen um überhaupt das Problem zu verursachen.

Man kann sich auch alles schön reden.

 *alexander_ro wrote:*   

> Wir reden hier aber nicht von der Runtime sondern Compiletime. Kernel und Module sind vollständig getrennte Übersetzungseinheiten.

 

Was ist für dich eine Übersetzungseinheit?

Wenn das für dich z.b. für c++ Übersetzungseinheit = *.cpp datei dann hat das null mit monolitisch oder nicht monolitisch zu tun. Dein problem ensteht zur link time und da gibt es diese Dateien nicht mehr sondern sonderen einzelne object files (*.o) welche vom Linker zu einer executable/library(shared object) zusammen gelinkt werden.

Für mich ist dann monolitisch wenn alle object files in eine executable/library gelinkt werden.

 *alexander_ro wrote:*   

> Fakt ist der Kernel Compiliert locker vom Hocker und clang nicht ... klar nur ein kleiner Unterschied aber wichtig.

 

Sicher dass der kernel bei dir auch mit -ggdb übersetz wird? Und der Kernel ist in C geschrieben und nicht in C++ wie clang...

----------

## firefly

 *Tyrus wrote:*   

> 
> 
> Die Ursache - darauf hatte mich franzf heute vormittag schon hingewiesen - ich bin mal so frei und schreib das hier jetzt einfach - danke für den Hinweis @franzf: 
> 
> https://github.com/gentoo/gentoo/blob/master/sys-devel/clang/clang-9.0.1.ebuild#L105
> ...

 

Nice catch. Ich vermute mal wenn man für clang 10 diese Option wie bei clang 9 setzt, dass dann das Problem bei alexander_ro nicht auftritt

----------

## Max Steel

 *firefly wrote:*   

>  *Tyrus wrote:*   
> 
> Die Ursache - darauf hatte mich franzf heute vormittag schon hingewiesen - ich bin mal so frei und schreib das hier jetzt einfach - danke für den Hinweis @franzf: 
> 
> https://github.com/gentoo/gentoo/blob/master/sys-devel/clang/clang-9.0.1.ebuild#L105
> ...

 

Ich versuche gerade von mgorny (der den Versionbump gepushed hat) zu erfahren warum er das so umsetzte... aber vll ist das auch direkt ein Bug in bgo wert...

----------

## mike155

 *franzf wrote:*   

> Zum Verifizieren, ob es wirklich ein gcc-bug ist, könnte man clang noch mit clang übersetzen und den Speicherverbrauch messen.
> 
> ```
> cat /etc/portage/env/clang.conf
> 
> ...

 

Gute Idee! Danke für den Tipp! Läuft gerade  :Smile: 

Ich habe folgendes direkt nach make.conf geschrieben:

```
###################################

MAKEOPTS="-j1"

CFLAGS="-O2 -pipe -ggdb"

CXXFLAGS="-O2 -pipe -ggdb"

CC=clang

CXX=clang++

###################################
```

Ich weiß nicht, ob das ausreichend ist, um vollständig auf clang umzustellen und ob es ein "fairer" Test ist. Aber es wird zumindest einen Hinweis darauf geben, ob clang Dateien generiert, die eine deutlich andere Größe haben.

Die ersten Aufrufe im Log sehen jedenfalls gut aus:

```
[336/1542] /usr/lib/llvm/10/bin/clang++ ... -O2 -pipe -ggdb ... 
```

----------

## mike155

...und die Testergebnisse. 

Szenario D: Clang 10 wird mit Clang 10 übersetzt. Hier funktioniert es mit 32 GB RAM (ohne Swap), MAKEOPTS="-j4" und /var/tmp/portage als tmpfs.

```
+---------------------------------+------------+------------+------------+------------+

|                                 | Szenario A | Szenario B | Szenario C | Szenario D |

+---------------------------------+------------+------------+------------+------------+

| Compiler                        |  GCC 9.3   |  GCC 9.3   |  GCC 7.5   |  Clang 10  |

| Flags (neben -O2 und -pipe)     |            |  -ggdb     |  -ggdb     |  -ggdb     |

+---------------------------------+------------+------------+------------+------------+

| Größe /var/tmp/portage          |    1.4 GB  |     24 GB  |     17 GB  |     17 GB  |

| Größe bin/clangd                |     14 MB  |   1370 MB  |    947 MB  |    548 MB  |

| Größe lib64/libclang.so.10      |     53 MB  |   2651 MB  |   1826 MB  |   1277 MB  |

+---------------------------------+------------+------------+------------+------------+ 
```

Ergebnis: Clang produziert mit "-ggdb" kleinere Dateien, als GCC

----------

## alexander_ro

Zeig mir doch mal die Rechnung von Dir die Belegt das 99% nicht in c/C++ geschrieben sind. 99% sind schon eine sehr Kommunistische Sicht. Bei denen wurden die Machthabe auch immer mit 99% gewählt wo keiner wusste wie die zustande kommen. Von den 995 Paketen bleiben genug die leicht das erfüllen um ähnlich Speicher kritisch zu sein. Es steht oben in einem meiner Texte das ich nicht glaube das es der gcc ist aber auch das ich es nicht Untersucht habe. Man kann aber auch notorisch alles von sich weißen das dem geliebten Baby zu nahe kommt. Ist ja nicht so das ihr bisher einen Beweis dafür hättet das es der gcc ist. Im übrigen beweist auch wenn clang clang übersetzen kann nicht das der gcc schuld ist bestenfalls das die das getestet haben und evtl. um Bugs/Designschwächen herum programiert . Der Kernel ist auch nicht an Spectre und Co. Schuld hat aber trotzdem die Probleme versucht zu beheben.

Es ist recht klar definiert was Übersetzungseinheiten sind. Ich will jetzt nicht anfangen einen Grundkurs in Programmierung hier zu schreiben. Ist schon richtig das es der Linker ist aber es ist ja jetzt nicht so das das nicht zur Übersetzung gehören würde. Ohne Linker hättest keine große Freude mit Deinen Programmen. Es müssen nicht unbedingt alle obj in einem File sein halt genug das es zu groß wird für gängige Hardware. Was zu groß ist ist Plattform abhängig. Man kann Großrechner Kriterien nicht am PC anlegen und PC nicht am Microcontroller. Ein Crash nach mehr als 16GB Speicherverbrauch ist für PC zu groß. Die Masse der PC Weltweit wird das nicht übersetzen können. Ich habe nirgends gelesen das clang für Großrechner gebaut wurde. Läuft der da Überhaupt? Mit dem gcc ging das vor einigen Jahren noch.

Ich weiß das der Kernel in C geschrieben wurde. Ja wird genauso Übersetzt ist Praktisch wenn man System Calls verfolgen will.

<Edit>

 *Quote:*   

> 
> 
> Szenario D: Clang 10 wird mit Clang 10 übersetzt. Hier funktioniert es mit 32 GB RAM (ohne Swap), MAKEOPTS="-j4" und /var/tmp/portage als tmpfs
> 
> 

 

Nur am Rande bemerkt sind 32GB keine 16 es würde daher immer noch nicht laufen. Was beweist das clang sich unter den gegebenen Bedingungen auch nicht mit clang bauen kann. Finde ich schon 

mal sehr interessant. Auch wenn ich nicht der Meinung bin das man das vergleichen kann. Zumal clang sich nicht bauen kann wenn ihn nicht vorher eine gcc oder andere gebaut haben.

</Edit>

----------

## firefly

 *alexander_ro wrote:*   

> Zeig mir doch mal die Rechnung von Dir die Belegt das 99% nicht in c/C++ 
> 
> geschrieben sind. 99% sind schon eine sehr Kommunistische Sicht. 

 

Ach du list wohl auch nur das was dir in den kram passt. Ich habe von 90-99%b geschrieben und nicht nur von 99%.

Und zusätzlich wirfst du schon wieder nur mit Beleidigungen um dich...

 *alexander_ro wrote:*   

> Von den 995 Paketen bleiben genug die leicht das erfüllen um ähnlich Speicher kritisch zu sein.

 

Wieder nur Behauptung ohne Beispiele. Und das ganze ist dann immer noch kein Beweis dass clang das problem ist.

Aber egal du willst keine Anderen Fakten hören als deine eigenen.

----------

## Tyrus

Also mein System ist ein 2-Core x86_64 Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz

Speicher ist 8GB.

Ich kompiliere immer mit -j3.

Swap-Speicher ist 16GB eingerichtet.

@Mike und @franzf:

Ich habe jetzt auch den clang mit clang bauen lassen. Der Unterschied ist wie Tag und Nacht. Die Last was den Swap-Verbrauch angeht lag bei 0,2 GB. Mit gcc war ich quasi am Limit. Selbst ohne Desktop und nur noch dazu top aktiv gab es bei den letzten  Steps minutenlange Hänger was den Refresh von top angeht. clang erzeugt da überhaupt keine Last und keine Hänger. 

Also mein Setup nochmal kurz:

In /etc/portage/env:

```

cat debugsyms

CFLAGS="${CFLAGS} -ggdb"

CXXFLAGS="${CXXFLAGS} -ggdb"

FEATURES="${FEATURES} splitdebug compressdebug -nostrip"

USE="debug"

```

```

cat installsources 

FEATURES="${FEATURES} installsources"

```

```

cat clang-conf 

CC=clang

CXX=clang++

```

Und in /etc/portage/package.env/

```

cat sys-devel/clang 

sys-devel/clang clang-conf debugsyms installsources

```

Dazu hab ich auch USE=debug für clang noch zusätzlich aktiviert.

--------

Dann gebaut mit:

```

time ebuild clang-10.0.0.ebuild compile

```

Fertig gebaut:

```

[...]

[1542/1547] cd /var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/utils/hmaptool && /usr/bin/cmake -E make_directory /var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/./bin && /usr/bin/cmake -E copy /var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang/utils/hmaptool/hmaptool /var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/./bin/

[1543/1547] : && /usr/lib/llvm/10/bin/clang++  -march=native -O2 -pipe -ggdb -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -pedantic -Wno-long-long -Wno-nested-anon-types  -Wl,-O1 -Wl,--as-needed    -Wl,-rpath-link,/var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/./lib64  -Wl,-O3 -Wl,--gc-sections tools/extra/clangd/fuzzer/CMakeFiles/clangd-fuzzer.dir/DummyClangdMain.cpp.o tools/extra/clangd/fuzzer/CMakeFiles/clangd-fuzzer.dir/clangd-fuzzer.cpp.o  -o bin/clangd-fuzzer  -Wl,-rpath,"\$ORIGIN/../lib64"  -lpthread  lib64/libclang-cpp.so.10  lib64/libclangDaemon.a  -lpthread  lib64/libclangToolingSyntax.a  lib64/libclangTidyAndroidModule.a  lib64/libclangTidyAbseilModule.a  lib64/libclangTidyBoostModule.a  lib64/libclangTidyCERTModule.a  lib64/libclangTidyDarwinModule.a  lib64/libclangTidyFuchsiaModule.a  lib64/libclangTidyHICPPModule.a  lib64/libclangTidyBugproneModule.a  lib64/libclangTidyCppCoreGuidelinesModule.a  lib64/libclangTidyGoogleModule.a  lib64/libclangTidyLinuxKernelModule.a  lib64/libclangTidyLLVMModule.a  lib64/libclangTidyMiscModule.a  lib64/libclangTidyModernizeModule.a  lib64/libclangTidyObjCModule.a  lib64/libclangTidyOpenMPModule.a  lib64/libclangTidyPerformanceModule.a  lib64/libclangTidyPortabilityModule.a  lib64/libclangTidyReadabilityModule.a  lib64/libclangTidyZirconModule.a  lib64/libclangTidyMPIModule.a  lib64/libclangTidyUtils.a  lib64/libclangTidy.a  lib64/libclangTooling.a  lib64/libclangStaticAnalyzerFrontend.a  lib64/libclangTransformer.a  lib64/libclangToolingRefactoring.a  lib64/libclangStaticAnalyzerCheckers.a  lib64/libclangStaticAnalyzerCore.a  lib64/libclangCrossTU.a  lib64/libclangIndex.a  lib64/libclangFormat.a  lib64/libclangToolingInclusions.a  lib64/libclangFrontend.a  lib64/libclangDriver.a  lib64/libclangParse.a  lib64/libclangSerialization.a  lib64/libclangSema.a  lib64/libclangEdit.a  lib64/libclangAnalysis.a  lib64/libclangASTMatchers.a  lib64/libclangToolingCore.a  lib64/libclangAST.a  lib64/libclangRewrite.a  lib64/libclangLex.a  lib64/libclangBasic.a  /usr/lib/llvm/10/lib64/libLLVM-10.so && :

[1544/1547] : && /usr/lib/llvm/10/bin/clang++ -fPIC -march=native -O2 -pipe -ggdb -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -pedantic -Wno-long-long -Wno-nested-anon-types  -Wl,-O1 -Wl,--as-needed -Wl,-z,defs -Wl,-z,nodelete   -Wl,-rpath-link,/var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/./lib64  -Wl,-O3 -Wl,--gc-sections  -Wl,--version-script,"/var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/tools/libclang/libclang.exports" -shared -Wl,-soname,libclang.so.10 -o lib64/libclang.so.10 tools/libclang/CMakeFiles/libclang.dir/ARCMigrate.cpp.o tools/libclang/CMakeFiles/libclang.dir/BuildSystem.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndex.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexCXX.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexCodeCompletion.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexDiagnostic.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexHigh.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexInclusionStack.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexUSRs.cpp.o tools/libclang/CMakeFiles/libclang.dir/CIndexer.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXComment.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXCursor.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXIndexDataConsumer.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXCompilationDatabase.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXLoadedDiagnostic.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXSourceLocation.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXStoredDiagnostic.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXString.cpp.o tools/libclang/CMakeFiles/libclang.dir/CXType.cpp.o tools/libclang/CMakeFiles/libclang.dir/Indexing.cpp.o tools/libclang/CMakeFiles/libclang.dir/FatalErrorHandler.cpp.o  -Wl,-rpath,"\$ORIGIN/../lib64"  lib64/libclangAST.a  lib64/libclangBasic.a  lib64/libclangDriver.a  lib64/libclangFrontend.a  lib64/libclangIndex.a  lib64/libclangLex.a  lib64/libclangSema.a  lib64/libclangSerialization.a  lib64/libclangTooling.a  /usr/lib/llvm/10/lib64/libLLVMSupport.a  lib64/libclangARCMigrate.a  lib64/libclangTidyPlugin.a  lib64/libclangIncludeFixerPlugin.a  -ldl  -lz  -lrt  -ldl  -ltinfo  -lm  /usr/lib64/libz3.so  /usr/lib/llvm/10/lib64/libLLVMDemangle.a  lib64/libclangTidyAndroidModule.a  lib64/libclangTidyAbseilModule.a  lib64/libclangTidyBoostModule.a  lib64/libclangTidyCERTModule.a  lib64/libclangTidyDarwinModule.a  lib64/libclangTidyFuchsiaModule.a  lib64/libclangTidyHICPPModule.a  lib64/libclangTidyBugproneModule.a  lib64/libclangTidyCppCoreGuidelinesModule.a  lib64/libclangTidyGoogleModule.a  lib64/libclangTidyLinuxKernelModule.a  lib64/libclangTidyLLVMModule.a  lib64/libclangTidyMiscModule.a  lib64/libclangTidyModernizeModule.a  lib64/libclangTidyObjCModule.a  lib64/libclangTidyOpenMPModule.a  lib64/libclangTidyPerformanceModule.a  lib64/libclangTidyPortabilityModule.a  lib64/libclangTidyReadabilityModule.a  lib64/libclangTidyZirconModule.a  lib64/libclangTidyMPIModule.a  lib64/libclangTidyUtils.a  lib64/libclangTidy.a  lib64/libclangStaticAnalyzerFrontend.a  lib64/libclangTransformer.a  lib64/libclangToolingRefactoring.a  lib64/libclangStaticAnalyzerCheckers.a  lib64/libclangStaticAnalyzerCore.a  lib64/libclangCrossTU.a  lib64/libclangIndex.a  -lpthread  lib64/libclangIncludeFixer.a  lib64/libfindAllSymbols.a  lib64/libclangTooling.a  lib64/libclangFrontend.a  lib64/libclangDriver.a  lib64/libclangParse.a  lib64/libclangSerialization.a  lib64/libclangSema.a  lib64/libclangEdit.a  lib64/libclangAnalysis.a  lib64/libclangFormat.a  lib64/libclangToolingInclusions.a  lib64/libclangToolingCore.a  lib64/libclangRewrite.a  lib64/libclangASTMatchers.a  lib64/libclangAST.a  lib64/libclangLex.a  lib64/libclangBasic.a  /usr/lib/llvm/10/lib64/libLLVM-10.so && :

[1545/1547] /usr/bin/cmake -E cmake_symlink_library lib64/libclang.so.10 lib64/libclang.so.10 lib64/libclang.so && :

[1546/1547] : && /usr/lib/llvm/10/bin/clang++  -march=native -O2 -pipe -ggdb -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -pedantic -Wno-long-long -Wno-nested-anon-types  -Wl,-O1 -Wl,--as-needed    -Wl,-rpath-link,/var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/./lib64  -Wl,-O3 -Wl,--gc-sections tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-test.c.o  -o bin/c-arcmt-test  -Wl,-rpath,"\$ORIGIN/../lib64"  -lpthread  lib64/libclang.so.10  /usr/lib/llvm/10/lib64/libLLVM-10.so && :

[1547/1547] : && /usr/lib/llvm/10/bin/clang++  -march=native -O2 -pipe -ggdb -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -pedantic -Wno-long-long -Wno-nested-anon-types  -Wl,-O1 -Wl,--as-needed    -Wl,-rpath-link,/var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/./lib64  -Wl,-O3 -Wl,--gc-sections tools/c-index-test/CMakeFiles/c-index-test.dir/c-index-test.c.o tools/c-index-test/CMakeFiles/c-index-test.dir/core_main.cpp.o  -o bin/c-index-test  -Wl,-rpath,"\$ORIGIN/../lib64"  -lpthread  lib64/libclang.so.10  lib64/libclangAST.a  lib64/libclangBasic.a  lib64/libclangCodeGen.a  lib64/libclangFrontend.a  lib64/libclangIndex.a  lib64/libclangSerialization.a  /usr/lib64/libxml2.so  lib64/libclangFrontend.a  lib64/libclangDriver.a  lib64/libclangParse.a  lib64/libclangSerialization.a  lib64/libclangSema.a  lib64/libclangAnalysis.a  lib64/libclangASTMatchers.a  lib64/libclangEdit.a  lib64/libclangFormat.a  lib64/libclangToolingInclusions.a  lib64/libclangToolingCore.a  lib64/libclangAST.a  lib64/libclangRewrite.a  lib64/libclangLex.a  lib64/libclangBasic.a  /usr/lib/llvm/10/lib64/libLLVM-10.so && :

>>> Source compiled.

```

Dauer:

```

real 111m49,690s

user 189m6,156s

sys  3m55,742s

```

Festplattenplatz nur noch 18GB (mit gcc waren es noch 32GB - aber da war auch die 32-BitVersion dabei):

```

pydf

[...]

/dev/INTENSO--EXTERN/TEST                                     471G   18G  451G  3.8 [............] /var/tmp/portage

[...]

```

Die erzeugen Binaries:

```

ls -la /var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/bin/

insgesamt 3464308

drwxr-xr-x 1 portage portage        960  9. Jul 17:33 .

drwxr-xr-x 1 portage portage        438  9. Jul 15:44 ..

-rwxr-xr-x 1 portage portage    3678168  9. Jul 16:40 arcmt-test

-rwxr-xr-x 1 portage portage      42272  9. Jul 17:33 c-arcmt-test

-rwxr-xr-x 1 portage portage  631016872  9. Jul 17:35 c-index-test

lrwxrwxrwx 1 portage portage          8  9. Jul 16:40 clang -> clang-10

lrwxrwxrwx 1 portage portage          8  9. Jul 16:40 clang++ -> clang-10

-rwxr-xr-x 1 portage portage    5393808  9. Jul 16:40 clang-10

-rwxr-xr-x 1 portage portage    2950752  9. Jul 16:40 clang-apply-replacements

-rwxr-xr-x 1 portage portage    9971288  9. Jul 17:11 clang-change-namespace

-rwxr-xr-x 1 portage portage    2340392  9. Jul 16:40 clang-check

lrwxrwxrwx 1 portage portage          8  9. Jul 16:40 clang-cl -> clang-10

lrwxrwxrwx 1 portage portage          8  9. Jul 16:40 clang-cpp -> clang-10

-rwxr-xr-x 1 portage portage    3596928  9. Jul 16:40 clang-diff

-rwxr-xr-x 1 portage portage   18509240  9. Jul 17:12 clang-doc

-rwxr-xr-x 1 portage portage    2916672  9. Jul 16:40 clang-extdef-mapping

-rwxr-xr-x 1 portage portage    1742632  9. Jul 16:40 clang-format

-rwxr-xr-x 1 portage portage    4433832  9. Jul 16:40 clang-import-test

-rwxr-xr-x 1 portage portage    7840968  9. Jul 17:13 clang-include-fixer

-rwxr-xr-x 1 portage portage   10030584  9. Jul 17:14 clang-move

-rwxr-xr-x 1 portage portage     924704  9. Jul 16:40 clang-offload-bundler

-rwxr-xr-x 1 portage portage    1764096  9. Jul 16:40 clang-offload-wrapper

-rwxr-xr-x 1 portage portage    8423320  9. Jul 17:14 clang-query

-rwxr-xr-x 1 portage portage    5461664  9. Jul 16:40 clang-refactor

-rwxr-xr-x 1 portage portage    1757272  9. Jul 16:40 clang-rename

-rwxr-xr-x 1 portage portage    5211968  9. Jul 16:40 clang-reorder-fields

-rwxr-xr-x 1 portage portage    1558144  9. Jul 16:40 clang-scan-deps

-rwxr-xr-x 1 portage portage   18129704  9. Jul 15:44 clang-tblgen

-rwxr-xr-x 1 portage portage  476064952  9. Jul 17:12 clang-tidy

-rwxr-xr-x 1 portage portage  573679688  9. Jul 17:20 clangd

-rwxr-xr-x 1 portage portage 1326201448  9. Jul 17:28 clangd-fuzzer

-rwxr-xr-x 1 portage portage   38593176  9. Jul 17:20 clangd-indexer

-rwxr-xr-x 1 portage portage  353568376  9. Jul 17:21 dexp

-rwxr-xr-x 1 portage portage    2266712  9. Jul 16:40 diagtool

-rwxr-xr-x 1 portage portage   10630240  9. Jul 17:13 find-all-symbols

-rwxr-xr-x 1 portage portage       9974  9. Jul 17:22 hmaptool

-rwxr-xr-x 1 portage portage   11970296  9. Jul 16:40 modularize

-rwxr-xr-x 1 portage portage    2850400  9. Jul 17:14 pp-trace

-rwxr-xr-x 1 portage portage      56477  9. Jul 15:44 scan-build

-rwxr-xr-x 1 portage portage       4702  9. Jul 15:44 scan-view

-rwxr-xr-x 1 portage portage    3770320  9. Jul 17:14 tool-template

```

Und dazu auch ein Blick auf Shared-Objects (in /var/tmp/portage/sys-devel/clang-10.0.0/work/x/y/clang-abi_x86_64.amd64/lib64/):

```

[...]

lrwxrwxrwx 1 portage portage         18  9. Jul 16:40 libclang-cpp.so -> libclang-cpp.so.10

-rwxr-xr-x 1 portage portage 1108008368  9. Jul 16:40 libclang-cpp.so.10

lrwxrwxrwx 1 portage portage         14  9. Jul 17:33 libclang.so -> libclang.so.10

-rwxr-xr-x 1 portage portage 1340230168  9. Jul 17:33 libclang.so.10

[...]

```

Mein Fazit:

Mit clang baut es sicher erheblich besser. Der Unterschied zu gcc ist riesig. Gerade auch weil quasi überhaupt kein Swap-Speicher benötigt wurde.Last edited by Tyrus on Thu Jul 09, 2020 4:47 pm; edited 1 time in total

----------

## alexander_ro

@firefly

Ähm wo bitte ist die Beleidigung ...

Ist egal ich habe das gekürzt stimmt schon aber ob 90-99 sehe ich keine Unterschied.

Stimmt ich weiß nicht genau was die 995 sind aber es sind einige C++ Sachen dabei. Oben stand extra nochmal 995 + meine ... ich kenne meine Programme ... wobei meine nicht heißt ich habe alles geschrieben sondern nur Projekte wo ich dran arbeite und den genauen Aufbau kenne. Das kommt an so ein clang Ding hin kannst Du glauben oder nicht ist Deine Entscheidung. Bei mit baute der clang auch bis vor kurzem noch auf nach eurer Meinung kaputten Hard und Software. Das habt ihr auch einfach so in den Raum geworfen ohne Beweise. Ich habe darauf hin sogar noch mal einige Sachen überprüft z.B. ob die SSD und Memory noch heil sind. Hätte ich da was gefunden hätte ich euch das auch mitgeteilt dem war aber nicht so. Der Rechner läuft auch viel zu Stabil seit Jahren als das SSD oder Speicher kaputt sein könnten.

Du hast genauso wenig Beweise ... 

Ich habe aber bereits Mehrfach geschrieben ich glaube nicht das es am gcc liegt habe es aber nicht Untersucht. Hier spekulieren alle nur weil bisher wenn ich es richtig sehe keiner den Fehler gefunden hat. Ich habe nie behauptet ich bin im Besitz der Absoluten Wahrheit. Ich kratze nur an einer heiligen Kuh so wie es aussieht.

Ich glaube nicht das ich keine anderen Fakten hören will sondern nur das ich meine Vermutung die ich als solche gekennzeichnet habe nicht einfach weg werfe weil jemand eine andere Vermutung in die Runde wirft. Nach mal ich habe es nicht Untersucht ...

Ich sehe euren Tests zu und warte was herauskommt.

<Edit>

```

Mit clang baut es sicher erheblich besser. 

```

Ganz großes Kino ...

nur zu blöde das ich clang nicht bauen kann also baut es sich mit clang ganz beschissen ...

</Edit>

----------

## Tyrus

@alexander_ro:

Wenn du nicht willst, willst du nicht ... sorry.

Du kannst auch clang-9 (den hattest du ja) für den Bau von clang-10 nutzen. Meine Ergebnisse hab ich mit clang-10 erzeugt richtig, weil er bei mir schon existiert. Aber ich sehe nix was darauf hindeutet das es sich beim Bau mit clang-9 wesentlich ändern würde.

----------

## alexander_ro

Ich will schon aber nur wenn einer einen Beweis liefert ... bisher gibt es den nicht meine Vermutung ist genauso gut wie Deine.

Ah ja stimmt clang 9 konnte ich bauen. Habe ich gerade verdrängt.

Aber das greift zu kurz weil eigentlich clang gar nicht das Problem ist sondern nur der Auslöser das ich etwas anderes tun will. Nämlich die Mozies (Mozilla) Software los werden. Ich mag die schon länger nicht mehr um genau zu sein seit der Umstellung auf Google Software. Nachdem die nach Google jetzt mit clang llvm auf weiter eher Kommerziell kontrollierte Software umstellen noch ein Grund mehr die los zu werden. Also stimmt ich könnte den clang mit einem alten bauen aber wo zu?

Bei einem Umstieg auf einen neuen Compiler sind meine Jahrzehnte Erfahrung nichts mehr wert weil man die Macken des neuen erst lernen muss. Dann stellt sich die Frage baut der auch wie der gcc Software für Mikrocontroller und andere CPU Plattformen. Also alle die ich brauche. Ich werde sicher nicht anfangen für alles einen eigenen Compiler zu verwenden das ist schlicht nicht mehr zu warten.

Der gcc mag nicht Optimal sein aber er kann halt extrem viel. Ob das clang auch könnte müsste ich erst mal herausfinden da fängt schon eine Menge Arbeit an. Da die C/C++ Standards viel Raum für Interpretationen lassen müsste ich vermutlich auch meine ganzen Programme erst mal auf clang portieren und dann erneut alles Testen. Es wäre nicht das erste mal das Software nach einem Compiler wechsel seltsame Dinge tut. Echt wo für ... das ich die gcc Macken gegen andere Macken tausche ... ich kenne keinen Compiler der keine Macken hat. clang kenne ich nicht er wäre aber der erste der 100% Fehlerfrei ist.

----------

## firefly

 *alexander_ro wrote:*   

> Bei mit baute der clang auch bis vor kurzem noch auf nach eurer Meinung kaputten Hard und Software. 

 

Wer hat das behauptet soweit ich das ganze hier überblicke hat das keine getan.

Das hauptproblem wieso clang 10 bei deiner RAM Ausstattung mit gcc 9.x und -ggdb nicht baut liegt daran, dass eine Option in der clang build konfiguration aktiviert wurde, welche dafür sorgt, dass alle clang libraries in eine libclang library zusammen gelinkt werden.

Das bedeutet nicht dass deine Hard und Software kaputt ist. Sondern nur dass dein System für diese spezielle build configuration nicht ausreicht!

Im clang 9 ebuild ist diese Option inaktiv daher funktioniert das bauen mit 16GB Ram.

 *alexander_ro wrote:*   

> Ich will schon aber nur wenn einer einen Beweis liefert ... bisher gibt es den nicht meine Vermutung ist genauso gut wie Deine.

 

Für was genau willst du denn einen Beweis?

Das deine RAM Ausstattung für das bauen von clang 10 mit debug symbolen nicht ausreicht wurde bewiesen.

Und die Faktoren die da mit reinspielen sind folgende

Das bauen mit -ggdb bläst die Dateigröße der einzelnen object files und die daraus erstellten libraries/executables zum teil massiv auf. Das erzeugt hauptsächlich dann beim linken einen massiven mehr Verbrauch von RAM

 Im clang 10 ebuild wurde eine optionale build option aktiviert welche dafür sorgt dass alles in eine Library gelinkt wird statt in 136 einzelne Libraries (wie bei clang9)

Also nochmal was wurde denn deiner Meinung nach nicht Bewiesen?

----------

## mike155

@Tyrus: schön, dass wir ähnliche Ergebnisse bekommen!  :Smile: 

Ich will noch 3 Tests durchführen:

Clang mit GCC 10 bauen

Clang aus Vanilla Source-Code (ohne portage) mit GCC bauen

Clang mit GCC aus Vanilla GCC-Code bauen

Mit den letzten beiden Tests möchte ich ausschließen, dass wir einem Gentoo-Bug hinterherrennen.

Und dann würde ich einen Bug bei den GCC Entwicklern einstellen - falls es niemand anderes machen möchte. Einen Vorläufer-Bug gibt es ja bereits: https://gcc.gnu.org/legacy-ml/gcc/2019-04/msg00270.html

----------

## alexander_ro

@firefly

Die Diskussion dreht sich doch die ganze Zeit um meine Vermutung es ist kein gcc Problem. Mike155 ich glaube er war es bin mir nicht sicher hat gemeint ich wolle nur nicht verstehen das es ein gcc Problem ist. Nur habt ihr bisher auch nur vermutet. Ich bin da nun schon so dreist und lasse mich von meinen Vermutungen nicht abbringen wenn alle anderen auch nur Vermuten. Nach Deiner Erklärung ist es ja doch das von mir Vermutet Problem das die sehr große Binärdateien zusammen linken. Wofür der gcc nichts kann damit bringt man irgendwann jede Memory Grenze zum Fallen. Sicher kann man die Fragen ob die an ihrer Speicherverwaltung noch was Optimieren können. Der in dem Bugreport hatte ja 2x128GB was noch eine ganze Ecke größer ist als bei mir. Aber egal wie ausgefeilt man Optimiert irgendwann ist der Speicher zu Ende man kann nicht beliebig große Binärdateien bauen. Sollte man auch nicht weil es nur Sinn macht wenn man sicher gehen will das alle die Schwächere Maschinen haben das nicht Nutzen können.

<Edit>

 *Quote:*   

> Wer hat das behauptet soweit ich das ganze hier überblicke hat das keine getan.

 

Max Stell war das glaube ich der meinte Hardware sei kaputt ... auch nur eine Vermutung.

<//Edit>

@Mike155

Wenn Du einen Bugreport schreibst schreib doch bitte den Link auch hier rein. Mich würde schon interessieren was die dazu sagen. Ich verstehe das zwar nur immer schlecht aber lesen ist leichter als selber in einer Fremdsprache Texte zu schreiben die andere Verstehen. Dazu kann ich das nicht genug.

----------

## Tyrus

@alexander_ro:

Deine Vermutung das der clang "ein schlechtes Design hat" (das waren deine Worte weiter oben), ist für mich nicht nachvollziehbar.

Tatsache ist der clang-9 baut bei dir mit -ggdb.

Tatsache ist auch das clang-10 die Shared-libs 'monolitischer' baut als clang-9 mit den Ebuilds die Gentoo dafür bereitstellt.

Du hast dann festgestellt das du clang-10 nicht gebaut bekommst und dabei Speichergründe als Ursache genannt.

Das es natürlich eben doch  an der Einstellung von -ggdb liegt - das ist dein Problem. 

Gerade diese Einstellung führt zu massiv mehr benötigtem Arbeitsspeicher und auch Festplattenspeicher.

Was hier gerade stattfindet ist einfach festzustellen wie der gcc arbeitet wenn man die Debugsysmbole baut. 

Dabei fällt (mir) auf das gcc-9.3.0 sehr schlechte Performance hat wenn man Debugsymole baut. Das war bei Mike so und ich habe es auch genauso getestet. Ich habe es gerade so hinbekommen clang-10 mit gcc-9.3.0 und vollständigen Debugsysmbolen zu bauen. Bei dir gings ja schon nicht mehr ....

Ein Vergleich dazu ist dann clang-10 mit clang-10 als rebuild nochmal zu compilieren. Das ergibt (bei mir) das jetzt fast kein Swap-Speicher benötigt wird (mit gcc-9.3.0 war ich bei fast 16GB Swap-Last für das Verlinken). Auch der Bedarf an Festplattenspeicher sinkt deutlich.

Dazu kommt das mein System auch nur 8GB hat und es auch nur 2 Prozessoren sind und das trotzdem mit -j3 gebaut wird. Die gleichen Einstellungen hatte ich auch bei gcc-9.3.0 getestet.

Du hast an keiner einzigen Stelle mal gezeigt das clang irgendetwas schlechter macht als gcc. Du stellst das einfach nur in den Raum das clang schlechtes Design hat weil gcc-9.3.0 da versagt. Du siehst den Grund in einem monolitischen Bau.

Dabei wird dieser eben nicht durch clang selber verursacht sondern basiert auf einer Entscheidung der Maintainer des Gentoo-Pakets (aber erst ab Version 10). Clang bietet die Möglichkeit dazu an, das ist richtig, aber warum man sich entschieden hat diesen Weg zu gehen wissen die Gentoo-Maintainer. 

Ausserdem - weder die Entwickler von clang noch die Gentoo-Maintainer des Paketes werden davon ausgehen, das der normale Benutzer das mit Debugsysmolen bauen will. Du verwendest da eine sehr spezielle Konfiguration.

Das solltest du auch so sehen. 

Das eventuell (auch) ein Bug beim gcc vorliegen könnte das versuchen die Test hier noch rauszufinden. 

PS:

Wenn du zeigen willst das clang eine schlechte Performance hat im Vergleich zum gcc nimm dir ein Paket - lass es bauen mit gcc-9.3.0 - und das gleiche nochmal mit clang-10. Liefer Testergebnisse dazu. Wenn du auch nur eins hast das mal das Gegenteil zeigt, könnte ich verstehen warum du zu deiner Vermutung kommst. So aber - ich kann wirklich gar nix mit deiner knapp 1000 Paketen anfangen die gcc bisher ohne Probleme gebaut hat. Ohne Probleme ist "relativ". Es ging ohne das es dir aufgefallen ist, so kann ich es auch deuten. Und dazu kommt das die wenigsten Pakete dann mit clang vergleichbar sind - gerade im Zusammenhang mit der Problematik die Debugsymbole da ausmachen.Last edited by Tyrus on Thu Jul 09, 2020 8:30 pm; edited 1 time in total

----------

## alexander_ro

Also ganz Ehrlich wenn Du den Unsinn glaubst den Du schreibst bist selber Schuld.

Gentoo als Sourcecode Distribution und geht nicht davon aus das wer das Debuggen möchte. Wenn ich nie was an der Software ändern oder untersuchen will brauch ich kein Gentoo und Debugger sind das Klassische Untersuchungswerkzeug. Es ist nicht mein Problem wenn die bei clang Optionen zum einschalten von schlechtem Design einbauen. Die Option zu haben ist schon schlechtes Design. Da kann der gcc nichts dafür wer hier versagt sind die Entwickler von clang.

Zumal man wenn man die Monotliherei zur Spitze treibt versagt der clang genauso. Speicher ist Endlich auch wenn das in eure Schädel nicht rein geht.

Wenn die Gentoo Entwickler nicht davon ausgehen das man eine Sourcecode Distribution zu Experimentieren benutzt dann haben die ihr eigenes Konzept nicht verstanden.

PS:

Hast Du jemals den Titel dieses Threads gelesen scheint nicht so.

Da steht "out of memory" ich dachte ihr könnt alle Englisch.

Da steht nicht "out of perfomance" ...

Ja wenn Du mal lesen würdest und nicht in der Manischen clang Schutzstare stecken würdest könntest Du vielleicht erkennen das es nicht um Performance geht. Das clang kaputt gehen kann hatte ich bereits Bewiesen beim ersten Beitrag.

Ich bin mal Neugierig was die gcc Entwickler von eurem Bugreport halten. Mal sehen was die finden ... es bleibt Spannend ...

 *Quote:*   

> so kann ich es auch deuten

 

Ja Du deutest viel leider meistens falsch ... aber klar wie immer bin ich natürlich Schuld ... klar wer sich traut an der heiligen Kuh zu kratzen ist der Arsch vom Dienst ...  :Sad: 

----------

## Tyrus

Erstmal wird clang nicht für Gentoo entwickelt. Und zweitens ist es völlig ungewöhnlich alles mit Debugsymbolen zu bauen wie du das machst. 

Wenn ich Debugsymbole für ein so grosses Paket wie clang aktiviere dann kann man wohl erwarten, das man auch ein System hat, das das kann was Speicher angeht. Deins kann es nicht ... 

Beantworte mir mal die Frage wozu baust du Debugsymbole beim clang? Nutzt du die wirklich für irgendwas?

Wenn ich jetzt mal ein anderes krasse Paket nehme wie die qtwebengine und da dann noch -gddb aktivieren würde  - das mein System das wohl nicht mehr schafft würde mich nicht verwundern. Zumindest wenn ich gcc dafür nehme. 

Was die Performance angeht - das bezieht sich auf deine unhaltbare Aussage clang hat ein schlechtes Design. Das berücksichtigt nicht alleine die Überschrift. Ich nehme nur das was du auch geschrieben hast ... es ist gar nicht an deinem Out-of-Memory verantwortlich. Es ist auch gar nicht monolitisch sondern kann sehr modular gebaut werden (war so bis Version 9). Es liefert ausserdem deutlich bessere Ergebnisse als gcc im Vergleich.

So und nun bin ich raus ... lohnt wirklich nicht weiter zu diskutieren.

----------

## alexander_ro

Wofür wurde denn clang Entwickelt?

Ein Compiler der nicht compilieren will (z.B Gentoo) braucht genau wer?

Gut erwarten kannst Du alles ... ich weiß es nervt aber es zeugt nicht gerade von Professioneller Arbeit wenn ein Programm auf weit verbreiteter Hardware nicht funktioniert. Ist ja nun nicht so das ich einen Pentium mit 256MB RAM verwende. Dann sollten die Macher halt angeben das er Großrechner Only ist.

Wenn es damit Probleme gibt benutze ich die ja. Ist jetzt bei clang im Moment gerade nicht der Fall. Wenn ich Firefox und Thunderbird ersetze in Zukunft auch nicht mehr. Firefox hat gerde wieder so eine Merkwürdige Meldung angezeigt man solle nicht Upgraden weil PGP dann kaputt geht. Die machen die Erweiterungen kaputt weil die irgendwelche Schnittstellen im Schnellschuss umbauen sind aber erst in Jahren fähig das kaputt gemachte zu ersetzen. Also ehrlich wer so Dumm ist der hat nicht mehr verdient als das er von den Rechnern fliegt.

qt allgemein und qtwebengine konnte der alles bauen selbst mit der -j8 die ich vorher hatte. Ich benutze qt für Projekte qt hat ja dafür den eingebauten Webbrowser.

Ich weiß ja nicht was Du machst ... aber mal angenommen Du würdest Software Entwickeln ... gehst Du dann zu Deinem Chef und sagst: die Software kann man nicht bauen weil der Speicher nicht reicht aber ich bin fertig mit der Arbeit? Ich denke die nächste Tätigkeit von Deinem Fiktivem Chef wäre das Aufsetzen des Kündigungsschreibens. Ich bin mir sicher Du würdest nicht so arbeiten aber so klingen die Argumente gerade.

----------

## franzf

 *alexander_ro wrote:*   

> Es ist nicht mein Problem wenn die bei clang Optionen zum einschalten von schlechtem Design einbauen. Die Option zu haben ist schon schlechtes Design. Da kann der gcc nichts dafür wer hier versagt sind die Entwickler von clang.

 

xD Ich hab es gewusst! Als ich gesehen hab dass clang die libs über eine builsystem-option als shared oder static bauen lässt, wirst du unterstellen, die Option wäre böööse!

Aber es ist GUUUUUT! Böse ist nur der Gentoo-Maintainer, der die Option nutzt (aus welchem Grund auch immer).

Warum ist das gut? libclang wird von vielen Editoren genutzt zur Code Completion (Sorry - Quelltextvervollständigung - muss mich zusammenreißen, man spricht selten mit Programmierern die kein Englisch können).

Wundert mich, dass du als C/C++-Programmierer mit jahrzehntelanger Erfahrung noch nicht in Berührung mit libclang als Vervollständigungswerkzeug gekommen bist.

Wenn man jetzt immer dutzende shared libs mitliefern muss, nur damit die libclang funktioniert, ist das unpraktisch. Vergiss eine und nix funktioniert mehr, die Programmierer beschweren sich, dass sie wieder die APIs selber in den headern nachschauen müssen.

Ich denke auch, dass ich gestern irgendwo gelesen hab, dass die Performance von clang runtergeht, wenn man die shared libs nutzt. kann sein dass das der Grund ist, warum das böse Gentoo die libclang.so als monolithischer Klotz baut.

Im übrigen versucht dich hier niemand zu bekehren.

Es ging von Anfang an darum, die Ursache für dein Problem zu finden.

Niemand versucht dich, zur heiligen Kuh zu bekehren, falls du es gemerkt hast haben erst zum Testen der Probleme hier die Leute angefangen, "clang" als CC und CXX zu setzen.

Ansonsten verwenden sie Superpony, äh, gcc (welches übrigens auch sehr monolithisch daherkommt),

Der Unterschied: gcc war lange Zeit ein C-Projekt, erst 2010 wurde daraus ein C++-Projekt.

Um die GCC-Entwickler nicht zu verscheuchen, die hauptsächlich gute C-Entwickler sind, hat man sich auf einige wenige Features festgelegt, und die "Experten-Funktionen" wie (AFAIR) Polymorphie, templates usw. ausgeschlossen - keine Ahnung wie das aktuell aussicht. Deshalb kompiliert und linked gcc immer noch schneller und mit weniger RAM als clang (wobei ich auf meinen 4GB auch gcc ohne -ggdb bauen musste, das ging oft gründlich schief).

clang auf der anderen Seite wurde von Anfang an von C++-Experten mit allen C++-Features entworfen.

Es würde mich freuen, wenn diese ganze Debatte ein Ende hätte, weil hier wirklich ein Problem besteht.

Nämlich dass sys-devel/clang-10.0 mit -ggdb mehr Speicher braucht als normale System haben. Dafür gibt es die check-reqs.eclass - prüfen, ob RAM und PORTAGE_TEMPDIR ausreichend groß sind.

Evtl. hat auch gcc ein Problem - dass object files unnötig aufgebläht werden, wenn man mit debug Symbolen baut.

Dafür kompilieren hier gerade fleißig einige Nutzer mit unterschiedlichen Konfigurationen und Compilern.

Das ist genial und ein Grund, warum ich Gentoo immer geliebt habe!

Und es ist doppelt löblich angesichts der vergifteten Atmosphäre, die hier von Seite 1 an geherrscht hat.

Bin gespannt auf die Ergebnisse!

----------

## firefly

Ich habe eventuell ein grund gefunden wieso die datei größe kleiner sind bei clang als bei gcc wenn mit  -ggdb gebaut wird.

Für debug symbole gibt es verschiedene levels (wieviel informationen enthalten sind). Aktuell gibt es 4 level (0-3)

Dafür gibt es auch spezifische parameter

- ggdb0

- ggdb1

- ggdb2

- ggdb3

Bei gcc ist der default level 2 -> ist identisch wenn man -ggdb2 explizit angibt.

Quelle: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

Abschnitt wo "-ggdblevel" beschrieben wird

 *Quote:*   

> Request debugging information and also use level to specify how much information. The default level is 2. 

 

Für clang konnte ich da nichts herausfinden welcher level default ist wenn man nur -ggdb angibt.

Daher sollte man wohl für einen besseren vergleich statt -ggdb eher -ggdb2 nehmen.

----------

## Max Steel

 *firefly wrote:*   

> Ich habe eventuell ein grund gefunden wieso die datei größe kleiner sind bei clang als bei gcc wenn mit  -ggdb gebaut wird.
> 
> Für debug symbole gibt es verschiedene levels (wieviel informationen enthalten sind). Aktuell gibt es 4 level (0-3)
> 
> Dafür gibt es auch spezifische parameter
> ...

 

Rein aus Interesse: Kann der Programmierer Einfluss darauf nehmen ob ein bestimmtes Symbol in einem bestimmten Level vorhanden sein muss?

Oder gibt es keinen Weg dazu und alle "Symbollevel" ergeben sich zu 100% Programmatisch?

----------

## firefly

 *Max Steel wrote:*   

> 
> 
> Rein aus Interesse: Kann der Programmierer Einfluss darauf nehmen ob ein bestimmtes Symbol in einem bestimmten Level vorhanden sein muss?
> 
> Oder gibt es keinen Weg dazu und alle "Symbollevel" ergeben sich zu 100% Programmatisch?

 

Ich weis es nicht aber ich würde vermuten dass der programmierer hier keinen Einfluss hat. Und der Level ist kein "symbol level" (falls ich dich richtig verstanden habe).

Der level gibt nur an wieviel debug informationen erzeugt werden sollen.

Aus der gcc Doku (wo leider level 2 nicht explizit beschrieben wird  :Sad: =

 *Quote:*   

> Level 0 produces no debug information at all.
> 
> Level 1 produces minimal information, enough for making backtraces in parts of the program that you don’t plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables.
> 
> Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.

 

Aber anhand  der definition von Level 1 was nicht enthalten ist würde ich vermuten dass in Level 2 mindestens die information über locale variablen mit enthalten ist.

Ah was gefunden: https://www.informit.com/articles/article.aspx?p=130865&seqNum=6

 *Quote:*   

> The default level is 2 (-g2), which generates extensive symbol tables, line numbers, and information about local and external variables

 

EDIT:

Und noch eine Quelle wo alle 4 Levels (0-3) beschrieben werden: https://books.google.de/books?id=yIJcDgAAQBAJ&pg=PA886&lpg=PA886&dq=gcc+level+2+ggdb&source=bl&ots=ztgd4a-Ptf&sig=ACfU3U0YMi94w5SKmc135jAc-5GL0QM4qg&hl=en&sa=X&ved=2ahUKEwiO3IeInsLqAhVK06YKHf4XCLU4ChDoATAAegQIChAB#v=onepage&q=gcc%20level%202%20ggdb&f=false

 *Quote:*   

> 0: This produces no debug information at all and is equivalent to omitting -g or -ggdb switch
> 
> 1: This produces little information but which includes function names and external variables which is enough to generate a back trace
> 
> 2: This is the default and incldues information about local variables and line numbers so that you can do source level debugging and  a single step through the code
> ...

 

----------

## alexander_ro

Aha jetzt braucht man also Optionen gegen die Vergesslichkeit Kommerzieller Produkthersteller ... toll das ist doch mal ein gutes Argument ...  :Sad:  Die Option ist nicht böse aber ungeschickt. Genauso wie es ungeschickt ist dutzende  - ich glaube es war auch schon mal von hunderten die Rede - libs zu haben. Gutes Design macht man nicht mit dem exzessiven Extremen sondern mit einem guten Mittelweg. Das kann auch mal eine peta Sekunde kosten ja aber die Nutzbarkeit und Wartbarkeit geht eindeutig vor. Das Problem  in der Software Entwicklung sind Fehler weniger fehlende peta oder nano Sekunden. Die meisten Entwickler besonders die aus den USA sind der Meinung wenn man sich Sklavisch an Muster und andere eher Akademische Lehren hält entsteht automatisch ein gutes Programm. Dem ist nicht so ganz besonders dann wenn man zu extremen neigt. Trotzdem kann man Muster und anderes als Ideen Geber verwenden muss sicher Kompromisse machen die zur eigenen Anforderung passen. Als Beispiel: beim Kernel machen die nicht für jeden Chip einen eigenen Treiber (extrem Modular) sondern für Chipfamilien Treiber (Kompromiss der zum Problem passt.).

Ich meinte nicht das ihr mich bekehren wollt sondern das ich den Eindruck habe Kritik ist nicht erlaubt weil clang Modern und gut sein muss weil er ... ja was ... neu ist?

Ich bin kein Fan von Code Completion (zwei Wörter kann ich meist schon übersetzen). Dann ist da aber auch was Faul wenn die Performance stark Abfällt wenn man Modular baut. Vielleicht der Fehlende Mittelweg den ich oben im Text erwähnt habe ...  :Smile: 

<Edit>

Ja der Level zwei enthält alles an Symbolen die ich bisher gebraucht habe. Das ist praktisch wenn ein Prozess zicken macht oder Plötzlich mehr Rechenzeit verbrät als er sollte kann man mit dem gdb den gerade Laufenden Prozess untersuchen. Programm beenden mit Symbolen neu bauen und der Fehler tritt nicht mehr auf. Ist mir schon oft passiert das der Neustart des Programms den Fehler erst mal verschwinden lies dann kann man ewig Spielen bis man den Zustand wieder erreicht. Meist reicht es wenn man die Symbolnamen und den Assemblercode hat um etwa zu wissen was abläuft. Reicht das nicht kann man immer noch ohne den Prozess zu beenden den Sourcecode dazu laden. Echt gut was der gdb da so alles kann.

</Edit>

----------

## franzf

 *firefly wrote:*   

> Für clang konnte ich da nichts herausfinden welcher level default ist wenn man nur -ggdb angibt.
> 
> Daher sollte man wohl für einen besseren vergleich statt -ggdb eher -ggdb2 nehmen.

 

Oder kurz testen, wie sich das alles größenmäßig verhält  :Wink: 

```
#include <boost/property_tree/ptree.hpp>

#include <boost/property_tree/ini_parser.hpp>

int main() {

    boost::property_tree::ptree cfg;

    boost::property_tree::read_ini("~/.notmuch-config", cfg);

}
```

Da das Programm nicht laufen muss, dürfte egal sein, ob bei euch .notmuch-config existiert  :Wink: 

Übersetzen, hab "-O2" als Optimierung gesetzt, der "*_default" wurde komplett ohne Optionen übersetzt. Namen sollten hoffentlich Sinn ergeben:

```
❯ ls -l ini_parser_{gcc,clang}*

-rwxr-xr-x 1 franz franz  223936 Jul 10 13:13 ini_parser_clang_default

-rwxr-xr-x 1 franz franz 1058976 Jul 10 13:21 ini_parser_clang_ggdb

-rwxr-xr-x 1 franz franz   69160 Jul 10 13:07 ini_parser_clang_ggdb0

-rwxr-xr-x 1 franz franz  203384 Jul 10 13:07 ini_parser_clang_ggdb1

-rwxr-xr-x 1 franz franz 1058976 Jul 10 13:07 ini_parser_clang_ggdb2

-rwxr-xr-x 1 franz franz 1058976 Jul 10 13:08 ini_parser_clang_ggdb3

-rwxr-xr-x 1 franz franz   69160 Jul 10 13:12 ini_parser_clang_nodbgflag

-rwxr-xr-x 1 franz franz  235264 Jul 10 13:13 ini_parser_gcc_default

-rwxr-xr-x 1 franz franz 1322728 Jul 10 13:20 ini_parser_gcc_ggdb

-rwxr-xr-x 1 franz franz   75784 Jul 10 13:08 ini_parser_gcc_ggdb0

-rwxr-xr-x 1 franz franz  386920 Jul 10 13:09 ini_parser_gcc_ggdb1

-rwxr-xr-x 1 franz franz 1322728 Jul 10 13:09 ini_parser_gcc_ggdb2

-rwxr-xr-x 1 franz franz 1865424 Jul 10 13:09 ini_parser_gcc_ggdb3

-rwxr-xr-x 1 franz franz   75784 Jul 10 13:12 ini_parser_gcc_nodbgflag
```

Ich denke, clang hat eigentlich nur 3 debug-levels, -ggdb3 ist da um kompatibel zu gcc zu bleiben.

Und - wichtig - "-ggdb" wählt bei beiden "-ggdb2". Der Größenzuwachs ist auch vergleichbar, von demher sollte es fair sein, CC und CXX einfach auf clang zu setzen ohne zusätzlich das ggdb-level anzupassen.

Zum Spaß noch ein kleiner Strip-tease:

```
❯ ls -l iniparser_strip 

insgesamt 520

-rwxr-xr-x 1 franz franz 47592 Jul 10 13:21 ini_parser_clang_ggdb

-rwxr-xr-x 1 franz franz 47592 Jul 10 13:21 ini_parser_clang_ggdb0

-rwxr-xr-x 1 franz franz 47592 Jul 10 13:21 ini_parser_clang_ggdb1

-rwxr-xr-x 1 franz franz 47592 Jul 10 13:21 ini_parser_clang_ggdb2

-rwxr-xr-x 1 franz franz 47592 Jul 10 13:21 ini_parser_clang_ggdb3

-rwxr-xr-x 1 franz franz 55848 Jul 10 13:21 ini_parser_gcc_ggdb

-rwxr-xr-x 1 franz franz 55848 Jul 10 13:21 ini_parser_gcc_ggdb0

-rwxr-xr-x 1 franz franz 55848 Jul 10 13:21 ini_parser_gcc_ggdb1

-rwxr-xr-x 1 franz franz 55848 Jul 10 13:21 ini_parser_gcc_ggdb2

-rwxr-xr-x 1 franz franz 55848 Jul 10 13:21 ini_parser_gcc_ggdb3
```

Ich habe nicht Speicherverbrauch und Compilezeit gemessen, dafür ist das Programm zu klein.

PropertyTree ist aber ausreichend komplex um ein wenig den Compiler zu fordern.

----------

## franzf

 *alexander_ro wrote:*   

> Aha jetzt braucht man also Optionen gegen die Vergesslichkeit Kommerzieller Produkthersteller ... toll das ist doch mal ein gutes Argument ...  Die Option ist nicht böse aber ungeschickt.

 

Bitte lass doch die Tiraden. Es will dir niemand was böses, du wirst nicht erreichen, dass sich clang ändert, noch wirst du uns überzeugen. Einfach weil es unwichtig ist.

Es geht auch nicht um Vergesslichkeit und erst recht nicht kommerzielle Produkte. Heutzutage - dank LTS-Distributionen, die nicht aktuell sein können - wird vieles an Opensource-Software als Flatpak o.Ä. verteilt. Dort sind die Abhängigkeiten mit enthalten. Für Editoren heißt das, dass sie libclang mitliefern müssen.

clang kann übrigens noch viel mehr als nur kompilieren und code-completion. Du bekommst z.B. direkt feedback zu Fehlern, die du machst, refactoring wird einfacher, undundund. Schau mal die features von clangd: https://clangd.llvm.org/features.html

clang-analyze ist auch großartig: https://clang-analyzer.llvm.org/

Es macht also Sinn, clang im Code-Editor zuverwenden.

Das heißt nicht, dass du das verwenden musst! Aber es wäre schön, wenn du zumindest Respekt für andere OpenSource-Projekte haben würdest, auch wenn sie aus Amerika kommen

----------

## alexander_ro

 *Quote:*   

> 
> 
> Bitte lass doch die Tiraden. Es will dir niemand was böses, du wirst nicht erreichen, dass sich clang ändert, noch wirst du uns überzeugen.
> 
> 

 

Ahm Triaden ja ... logisch auch nur ich ... keiner hat je ein Antwort geschrieben ...  :Sad: 

Ich will gar niemanden ändern das Einzige was mich wirklich stört ist der Mozilla Compiler Zwang. Hat nichts mit euch zu tun und mit clang auch nicht.

Ich habe da nur meine Meinung zu geschrieben. Ich dachte bisher man dürfe das. Ich bin auch kein Fan von diesen Flatpack geschichten. Ein gewisser Trend nur der Bequemlichkeit wegen großzügig Ressourcen zu verschwenden.

 *Quote:*   

> direkt feedback zu Fehlern, die du machst, refactoring

 

Ich dachte einfach das wäre beim gcc auch so. Mich bewirft der Regelmäßig mit umfangreichen Fehlerhinweisen ...

Diese ganzen Verbesserungstools funktionieren aber nur wenn Du exakt nach Vorgabe denen Erfindern arbeitest.

Aber egal ich lasse das jetzt wenn es keiner wissen will. Kann man so vergessen niemand will noch Nachdenken ob es Sinnvoll ist was man tut. Warum auch China liefert billigen Speicher und Strom kommt aus der Steckdose.

 *Quote:*   

> 
> 
> Das heißt nicht, dass du das verwenden musst!
> 
> 

 

Leider ja doch weil wollte ich Mozilla Software benutzen muss ich clang benutzen.

----------

## franzf

 *alexander_ro wrote:*   

> quote]direkt feedback zu Fehlern, die du machst, refactoring

 

Ich dachte einfach das wäre beim gcc auch so. Mich bewirft der Regelmäßig mit umfangreichen Fehlerhinweisen ...[/quote]

Ja, aber erst wenn du selber kompilierst. Die Tools in der IDE integriert helfen die schon beim Tippen.

Da wird was unterkringelt -> ah, was schreib ich QString::toUper, heißt ja toUpper -> direkt verbessert während ich an der Stell mit dem Cursor sitze. Einfacher als erst nach dem kompletten Erstellen des Projektes an die Stellen mit den Fehlern zu springen.

 *Quote:*   

> Diese ganzen Verbesserungstools funktionieren aber nur wenn Du exakt nach Vorgabe denen Erfindern arbeitest.

 

Kein Tool macht alles immer sofort so wie du es willst, das fängt beim Desktop Environment an und hört beim Editor nicht auf. Wichtig ist , dass Tool und User flexibel genug sind, um sich dem gemeinsamen Ziel anzunähern. Und am Ende ist es die IDE/Editor, die die Funktionen von clang integrieren und Optionen usw. anbieten, die Steuerung des Refactoring, static analyzing, etc. anzupassen.

 *Quote:*   

>  *Quote:*   
> 
> Das heißt nicht, dass du das verwenden musst!
> 
>  
> ...

 

Kontext! Ich sprach von libclang-Integration im Editor/IDE. Wenn du das nicht haben willst zwingt dich niemand.

(Und wenn du firefox-bin/thunderbird-bin verwendest, kommst du ganz ohne clang auf deinem System aus.

Die immer wieder kritisierte Google-Technologie/Software, die dich am neuen Firefox stört, sind wahrscheinlich WebExtensions, korrekt?

Wenn du nen Browser gefunden hast, der das aktuell nicht verwendet -> lass es uns wissen!)

----------

## alexander_ro

Bei Integration in einen Editor kann sein das man die Wahl hat stimmt.

Ach so war das gemeint mit den Fehlern das habe ich wohl nicht richtig verstanden.

Nein oder auch eigentlich meinte ich die chrome Software im Firefox.

Ich weiß noch nicht was es sonst an Browser gibt muss erst noch einen suchen. Als Ersatz für Thunderbird verwende ich jetzt mal Roundcube das läuft so schon auf für meinen Mailserver. War halt praktisch weil Thunderbird nebenbei eine Sicherung der Mails angelegt hat. Aber das kann man auch anders lösen.

----------

## mike155

Ein Testergebnis mit GCC 10. Die Dateien sind gegenüber GCC 9.3 um 5% kleiner geworden. Die richtige Richtung, aber zu wenig  :Smile: 

```
+---------------------------------+----------+----------+----------+----------+----------+

|                                 |  Test A  |  Test B  |  Test C  |  Test D  |  Test E  |

+---------------------------------+----------+----------+----------+----------+----------+

| Compiler                        | GCC 9.3  | GCC 9.3  | GCC 7.5  | Clang 10 | GCC 10.1 |

| Flags (neben -O2 und -pipe)     |          | -ggdb    | -ggdb    | -ggdb    | -ggdb    |

+---------------------------------+----------+----------+----------+----------+----------+

| Größe /var/tmp/portage          |   1.4 GB |    24 GB |    17 GB |    17 GB |    23 GB |

| Größe bin/clangd                |    14 MB |  1370 MB |   947 MB |   548 MB |  1283 MB |

| Größe lib64/libclang.so.10      |    53 MB |  2651 MB |  1826 MB |  1277 MB |  2467 MB |

+---------------------------------+----------+----------+----------+----------+----------+
```

----------

## franzf

 *alexander_ro wrote:*   

> Nein oder auch eigentlich meinte ich die chrome Software im Firefox.

 

Ah! Ist mir gerade beim Gassi gekommen dass du das meinen könntest.

Nö, das hat nix mit Chrome (dem Browser) zu tun, da geht es um die Benutzeroberfläche:

https://developer.mozilla.org/de/docs/Mozilla/Chrome_Registration

Kannst also von dem her bedenkenlos weiter firefox einsetzen. Einfach firefox-bin installieren, da wird nix kompiliert und du brauchst keinen clang.

----------

## alexander_ro

Es wurde zumindest mal  irgendwann in der Fachpresse behauptet das Mozilla Gecko nicht mehr weiter entwickelt und zu chrome Rendering wechselt. Ist aber schon ewig her das ich das mal gelesen habe.

Nein erst mal werde ich das nicht mehr tun das war wie weiter oben steht nicht der einzige Grund. Mal sehen was dabei herauskommt.

----------

## alexander_ro

Gibt scheinbar schon mehr Projekte die glauben ein Compiler Zwang sei eine Zeichen für Freie Software ...  :Sad: 

```

Calculating dependencies... done!

[ebuild  N     ] sys-devel/llvm-common-10.0.0 

[ebuild  N     ] sys-libs/libomp-10.0.0  USE="(-cuda) -hwloc -offload -ompt -test" ABI_X86="(64) -32 (-x32)" 

[ebuild  N     ] sys-devel/llvm-10.0.0  USE="libffi ncurses xml -debug -doc -exegesis -gold -libedit -test -xar -z3" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 

[ebuild  N     ] sys-libs/compiler-rt-10.0.0  USE="-clang -test" 

[ebuild  N     ] sys-libs/compiler-rt-sanitizers-10.0.0  USE="libfuzzer profile sanitize xray -clang -test" 

[ebuild  N     ] sys-devel/clang-runtime-10.0.0  USE="compiler-rt openmp sanitize -libcxx" ABI_X86="(64) -32 (-x32)" 

[ebuild  N     ] sys-devel/clang-10.0.0  USE="static-analyzer xml -debug -default-compiler-rt -default-libcxx -doc -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8" 

[ebuild  N     ] sys-devel/clang-common-10.0.0 

[ebuild  N     ] media-tv/v4l-utils-1.16.6  USE="bpf qt5 -opengl" 

Would you like to merge these packages? [Yes/No] no

```

----------

## franzf

gib emerge die Option "--tree" mit, dann siehst du, was lllvm und clang braucht.

Die genaue Ursache findest du im ebuild.

Hier:

https://gitweb.gentoo.org/repo/gentoo.git/tree/media-tv/v4l-utils/v4l-utils-1.16.6.ebuild#n30

Hier die Beschreibung des bpf-USE-Flags:

https://packages.gentoo.org/useflags/bpf

//edit:

Und da es sich hinter nem USE-Flag versteckt (was sich auf die build-Opzionen und somit Funktionsumfang der Software auswirkt) ist es kein Zwang.

Dass clang/llvm verwendet werden liegt daran, dass die Funktionen nicht mit gcc implementiert werden können.

----------

## alexander_ro

Da hatte ich schon rein geschaut was ist den bpf? sagt mir jetzt nix.

```

alien /etc/portage/env # emerge --ask --tree media-tv/v4l-utils

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.

 * Use eselect news read to view new items.

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild  N     ] media-tv/v4l-utils-1.16.6  USE="bpf qt5 -opengl" 

[nomerge       ]  sys-devel/clang-10.0.0  USE="static-analyzer xml -debug -default-compiler-rt -default-libcxx -doc -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8" 

[ebuild  N     ]   sys-devel/clang-common-10.0.0 

[ebuild  N     ]    sys-devel/clang-10.0.0  USE="static-analyzer xml -debug -default-compiler-rt -default-libcxx -doc -test" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" PYTHON_SINGLE_TARGET="python3_7 -python3_6 -python3_8" 

[ebuild  N     ]     sys-devel/clang-runtime-10.0.0  USE="compiler-rt openmp sanitize -libcxx" ABI_X86="(64) -32 (-x32)" 

[ebuild  N     ]      sys-libs/compiler-rt-sanitizers-10.0.0  USE="libfuzzer profile sanitize xray -clang -test" 

[ebuild  N     ]      sys-libs/compiler-rt-10.0.0  USE="-clang -test" 

[ebuild  N     ]       sys-devel/llvm-10.0.0  USE="libffi ncurses xml -debug -doc -exegesis -gold -libedit -test -xar -z3" ABI_X86="(64) -32 (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 

[ebuild  N     ]        sys-devel/llvm-common-10.0.0 

[ebuild  N     ]      sys-libs/libomp-10.0.0  USE="(-cuda) -hwloc -offload -ompt -test" ABI_X86="(64) -32 (-x32)" 

Would you like to merge these packages? [Yes/No] 

```

... und wie sehe ich hier was die Ursache ist?

Sieht für mich aus wie die erste Liste anders sortiert und mit einer Menge mehr USE-Flags.

----------

## alexander_ro

Nicht Dein ernst: "Funktionen nicht mit gcc implementiert werden können"?

Was sollte man mit ihm nicht machen können?

Soll das das sein:

bpf = Berkeley Packet Filter (Paket Filter kann man nicht mit dem gcc bauen.) Hm ...

----------

## franzf

 *alexander_ro wrote:*   

> Nicht Dein ernst: "Funktionen nicht mit gcc implementiert werden können"?
> 
> Was sollte man mit ihm nicht machen können?

 

Doch, ist mein Ernst. Wenn du etwas nicht kennst oder verstehst, frag bitte in Zukunft normal nach, dann bleibt das Klima freundlich.

Es geht um Infrarot-Fernbedienungen (wie es aussieht):

https://lwn.net/Articles/759188/

Auf Deutsch kannst du den Artikel lesen, wenn du die obige URL kopierst und bei translate.google.com einfügst.

Das gibt dir rechts nen Link, der den übersetzten Text enthält.

Der entscheidende Teil:

"A BPF program can be written in a number of different ways, but the easiest way is to use clang with the target BPF. This allows the BPF program to be written in a sort of restricted C that does not allow the use of C-library functions or loops, for example."

Also grob: "BPF-Programme kann man auf viele Arten schreiben, aber am einfachsten ist es mit clang unter der Verwendeung des BPF targets. Damit kann man das Programm in einer Art reduziertem C schreiben." [Anm: und C kann man besser verstehen als irgendwelche kryptischen/exotischen Sprachen.]

----------

## franzf

 *alexander_ro wrote:*   

> Da hatte ich schon rein geschaut was ist den bpf? sagt mir jetzt nix.
> 
> ```
> 
> alien /etc/portage/env # emerge --ask --tree media-tv/v4l-utils
> ...

 

Das ist ne Baumansicht von den Abhängigkeiten. Du siehst da sofort, dass v4l-utils direkt clang als Abhängigkeit verlangt. clang braucht clang-common usw.

So kannst du (vor allem bei längeren Listen) direkt ungewollte Abhängigkeiten erkennen und aussortieren.

War immer wieder recht nützlich, wenn plötzlich irgendwas wieder geoclue oder den ganzen modemmanager- und blutooth-Kram reingezogen hat (was ich nicht brauche, weil ich weder blutooth noch modem im Laptop hab).

----------

## alexander_ro

Ja das ist gut zu wissen. Ich habe da jetzt immer mit "equery depends <Paketname>" gesucht. Aber das von Dir sieht übersichtlicher aus weil es sich auf das eine Paket beschränkt davon aber alles.

Die haben in eine neue Programmiersprache und VM erfunden die der gcc nicht unterstützt. PHP kann der auch nicht aber deshalb könnte man das mit dem Implementieren man müsste halt ein Sprache verwenden die zu Umfang der Unterstützten Sprachen gehört. Die Google Übersetzungen benutze ich schon aber die sind oft echt Schlecht. Google hat nur gute Übersetzungen wo Menschen gute Übersetzungen geliefert haben. Ist nicht so das da alles maschinell gemacht würde.

Ich habe doch gefragt ob es Dein ernst ist das war jetzt nicht unfreundlich gemeint. Hier sagt man das so wenn eine Erklärung Überraschender ist als erwartet.

<Edit>

Ja stimmt ich habe das mal aus gemacht dann geht auch mit dem gcc. Das ist ein Digitales Mikroskop da brauch ich keine Infrarot Fernbedienung. Die Seite von Dir zur Infrarotfernbedienung ist gut die hatte ich nicht gefunden. Mir war aber auch nicht gleich klar das die Fernbedienungen meinen.

Ich weiß bei den ebuilds leider nicht wirklich was die da tun und bin auch nicht gleich auf die Idee gekommen das bpf? ein USE-Flag meinen könnte. 

</Edit>

----------

## schmidicom

Hier wurde einige male über die Vorzüge vom GNU Gold Linker gegenüber dem GNU BFD Linker diskutiert und einige scheinen den sogar als Standard verwenden, aber wie sieht es disbezüglich mit dem LLD Linker aus dem LLVM-Projekt aus? Hat den auch schon mal jemand als Standard ausprobiert?

Ich habe mal versucht diesen bei ein paar kleineren Paketen zu verwenden und bis jetzt scheint er bestens zu funktionieren. Sogar der Kernel unterstützt dessen Verwendung, ganz im Gegensatz zum GNU Gold Linker.

PS: Über den RAM-Verbrauch vom LLD weiss ich jetzt nichts aber die Performance soll angeblich deutlich besser sein, was bei Paketen wie "app-office/libreoffice" oder "dev-qt/qtwebengine" sicher interessant sein könnte.

https://lld.llvm.org/#performance

EDIT:

Ich habe den LLD über folgende Konfigurations-Datei ausprobiert.

```
LDFLAGS="${LDFLAGS} -fuse-ld=lld"
```

----------

## firefly

 *schmidicom wrote:*   

> Hier wurde einige male über die Vorzüge vom GNU Gold Linker gegenüber dem GNU BFD Linker diskutiert und einige scheinen den sogar als Standard verwenden

 

Wobei der gold linker von google nicht mehr weiterentwickelt wird (https://www.phoronix.com/scan.php?page=news_item&px=GNU-Gold-Stagnate-F31)

----------

## alexander_ro

Interessant ich wusste bisher nicht mal das es beim llvm einen Linker gibt. Deshalb habe ich den auch noch nie ausprobiert.

Ich tendiere aber dazu wenn es keinen wichtigen Grund gibt das zu ändern die Default Tools der Projekte zu verwenden. Also im falle vom gcc den BFD Linker. Wenn ich das richtig übersetzt habe ist der golden Linker nur für spezial Fälle gemacht worden. Da ich auch auf verschiedenen Plattformen Entwickle muss ich auch immer schauen ob die Tools auf allen laufen. Ich werde nicht anfangen auf jeder Plattform eine eigene Entwicklungsumgebung zu betreiben. Hat man überall die gleichen Tools kennt man schon die Eigenheiten und muss nur Plattformspezifisches dazu lernen.

Es gab bei Gentoo ja erst ein gcc Update das konnte der auf einem Raspi mit 1GB RAM und 1GB Swap mit -j2 bauen. Dauert zwar sehr lange aber das kann gut übernacht laufen. Man kann - da nur zwei von vier Kerne benutzt werden - mit dem Raspi sogar nebenbei andere Dinge machen. Also ich für meinen Teil bleibe erst mal bei dem gcc mit default Linker.

In der Konfigurationsdatei legt man fest welchen Linker Portage verwenden soll?

----------

## schmidicom

 *alexander_ro wrote:*   

> ...
> 
> Da ich auch auf verschiedenen Plattformen Entwickle muss ich auch immer schauen ob die Tools auf allen laufen. Ich werde nicht anfangen auf jeder Plattform eine eigene Entwicklungsumgebung zu betreiben. Hat man überall die gleichen Tools kennt man schon die Eigenheiten und muss nur Plattformspezifisches dazu lernen.

 

Der LLD unterstützt so weit ich weiss mehrere Plattformen (Linux, MacOS und Windows).

 *alexander_ro wrote:*   

> In der Konfigurationsdatei legt man fest welchen Linker Portage verwenden soll?

 

Meine Konfigurationsdatei erlaubt es den Linker für einzelne Pakete zu ändern.

Alles weitere dazu findest du in der Gentoo-Doku: https://wiki.gentoo.org/wiki//etc/portage/package.env

Um es für alle Pakete zu ändern müsste man die Variable "LDFLAGS" in der "/etc/portage/make.conf" neu konfigurieren.

----------

## alexander_ro

 *Quote:*   

> /etc/portage/env/ld_lld

 

Ach das ist das gleiche wie die package.env. Gut zu wissen.

----------

## alexander_ro

Warum schreiben die Mozis auf Ihrer Internetseite

```

Current minimal requirement gcc 7.1

```

Wenn dann clang Zwang ist?

Ich verstehe das jetzt nicht wirklich aber man findet auch praktisch keine brauchbaren Infos dazu.

Was ist denn nun aus dem Bug geworden den der gcc laut eurer Aussagen hat wurde der gemeldet?

Ihr habt ja gemeint der Monolithbau ist Stat of the Art und der gcc könne nur nicht richtig mit dem Speicherumgehen. Ich frag nur weil wenn da was gemacht wurde würde ich es nochmal ausprobieren. Wenn nichts geändert wurde kann ich mir den Strom sparen.

----------

