Poudriere: llvm13 build failure

schorsch_76

FreeBSD Fanboy
Hallo,

ich versuche gerade meinen poudriere wieder zum bauen zu bekommen. Leider bricht es immer ab mit

FAILED: tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.cpp.o
FAILED: tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-complex.cpp.o
/FAILED: tools/flang/lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-real.cpp.o
(ich hab mal die CC Zeilen raus genommen zur Steigerung der Übersicht). Ich hab 2022Q2 und main probiert als port branch. MAKE_JOBS_UNSAFE=yes müsste ja im Port Makefile gesetzt werden. Das hab ich nicht gemacht. ein "pkg show llvm13" mit dem Repo von FreeBSD zeigt mir das FLANG gesetzt ist, also muss es ja zum kompilieren gehen.

Mein Aufruf zum bauen ist wie folgt:
poudriere bulk -j 131amd64 -p 2022Q2 -f /usr/local/etc/poudriere.d/packages-test

in der packages-test steht nur devel/llvm13

Die Maschine ist wie folgt: (CPU Temperatur ist gerade bei 84°C weil gerade ein poudriere build ohne FLANG läuft).... FreeBSD hat seine eigene 1TB SSD mit einem zfs drauf. Die anderen Platten sind andere Betriebsysteme.

[georg@Hammerhead ~]$ inxi -F
System:
Host: Hammerhead Kernel: FreeBSD 13.1-RELEASE amd64 bits: 64
Desktop: KDE Plasma 5.24.5 OS: FreeBSD 13.1-RELEASE
Machine:
Permissions: Unable to run dmidecode. Root privileges required.
CPU:
Info: 16-core model: AMD Ryzen 7 3700X bits: 64 type: MCP MCM cache: N/A
Speed (MHz): 3593 min/max: N/A cores: No OS support for core speeds.
Graphics:
Device-1: AMD Curacao PRO [Radeon R7 370 / R9 270/370 OEM] driver: vgapci
Display: x11 server: X.Org 1.20.14 driver: loaded: modesetting
unloaded: vesa resolution: 1: 1680x1050~60Hz 2: 1680x1050~60Hz
OpenGL: renderer: AMD Radeon HD 8800 Series (PITCAIRN DRM 3.35.0
13.1-RELEASE LLVM 13.0.1)
v: 4.6 Mesa 21.3.8
Audio:
Device-1: AMD Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000
Series]
driver: none
Device-2: AMD Starship/Matisse HD Audio driver: hdac
Sound Server-1: OSS v: 2009061500 running: yes
Sound Server-2: PulseAudio v: 14.2 running: yes
Network:
Device-1: Intel I350 Gigabit Network driver: igb
IF: igb0 state: no carrier speed: N/A duplex: N/A mac: a0:36:9f:00:82:3e
Device-2: Intel I350 Gigabit Network driver: igb
IF: igb1 state: active speed: 1000baseT duplex: full-duplex
mac: a0:36:9f:00:82:3f
RAID:
Device-1: zroot type: zfs status: ONLINE level: linear raw: size: 928 GiB
free: 880 GiB zfs-fs: size: 899.25 GiB free: 822.46 GiB
Components: Online: 1:
Drives:
Local Storage: total: raw: 2.27 TiB usable: 4.06 TiB used: 50.31 GiB (1.2%)
ID-1: /dev/ada0 vendor: Samsung model: SSD 870 EVO 1TB SVT02B6Q
size: 931.51 GiB scheme: GPT
ID-2: /dev/ada1 vendor: Samsung model: SSD 860 EVO 1TB RVT03B6Q
size: 931.51 GiB scheme: GPT
ID-3: /dev/ada2 vendor: Samsung model: SSD 850 EVO 500GB EMT03B6Q
size: 465.76 GiB scheme: GPT
Partition:
ID-1: / size: 835.81 GiB used: 13.35 GiB (1.6%) fs: zfs
logical: zroot/ROOT/default
ID-2: /tmp size: 822.46 GiB used: 91 KiB (0.0%) fs: zfs
logical: zroot/tmp
ID-3: /usr/home size: 825.26 GiB used: 2.8 GiB (0.3%) fs: zfs
logical: zroot/usr/home
ID-4: /var/log size: 822.46 GiB used: 650 KiB (0.0%) fs: zfs
logical: zroot/var/log
ID-5: /var/tmp size: 822.46 GiB used: 24 KiB (0.0%) fs: zfs
logical: zroot/var/tmp
Swap:
ID-1: swap-1 type: partition size: 32 GiB used: 1021.4 MiB (3.1%)
dev: /dev/zvol/zroot/swap
Sensors:
System Temperatures: cpu: 84.1 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 163 Uptime: 59m Memory: 31.88 GiB used: 29.27 GiB (91.8%)
Shell: Bash inxi: 3.3.11

Hier noch die 131amd64.conf (sonst ist alles default) Hab das jetzt nur mal raus genommen um zu testen ob ich damit llvm gebaut bekomme.
OPTIONS_UNSET += FLANG
Hat jemand eine Idee?

EDIT: Build ohne FLANG erfolgreich nach 30 min.
 

Anhänge

  • poudriere.conf.txt
    11,2 KB · Aufrufe: 145
Zuletzt bearbeitet:
Also ist er gegen das Speicherlimit gelaufen. :) Das kann bei sehr großen Ports, gerade wenn sie in C++ und noch mindestens 10x schlimmer Rust geschrieben sind, schon mal passieren. Ich hatte mit llvm13 sogar mit 32 Gigabyte RAM noch Probleme, allerdings auch mit sehr vielen Buildern parallel.
 
Diese Einstellungen haben sicher geholfen und das System läuft trotz Bau mit poudriere so flüssig! Perfekt! libreoffice, gcc, qt5-webengine liefen parallel durch ohne Probleme!

firefox schlägt gerade fehl, weil es ein Problem mit der icu Version gibt.
 

Anhänge

  • Screenshot_20220525_150938.png
    Screenshot_20220525_150938.png
    449,4 KB · Aufrufe: 181
Das oben war etwas kurz angebunden. Die Out Of Memory Logik ist komplex und hat wie bei den meisten klassischen Unixes einige Einschränkungen. Schon seit einigen Versionen macht FreeBSD kein Overcommit mehr. Es gibt nur Speicher heraus, der entweder durch RAM oder Swap abgesichert ist. Wenn das System einer Allokation nicht mehr stattgeben kann, da aller Speicher zugewiesen ist, blockiert der die Allokation anfragende Prozess einige Zeit, bevor es erneut versucht wird. Das passiert einige Male und wenn es keinen Erfolg gibt, ist irgendwann Ende und der OoM-Killer schlägt zu. Er blockiert alles, wählt einen Prozess aus und killt diesen, um Speicher freizuräumen. Trifft es einen Compiler-Prozess, erkennt Poudriere es als Build Failure und der Build bricht ab. Es lässt sich aus der dmesg herauslesen, dass der OoM-Killer zugeschlagen hat.

Das Blockieren von Prozessen wird von dem Nutzer als ein stotterndes System wahrgenommen. Es betrifft sowohl startende Prozesse, die erstmal Speicher haben müssen, um zu laufen. Und auch ganz beliebt Browser, da sie wie irre allokieren und freigeben. Alles zu blockieren, ist natürlich gleich ein kompletter Aussetzer des Systems.

Die beiden sysctl verändern die OoM-Logik:
  • vm.pageout_oom_seq gibt an, wie lange der Prozess blockiert. 120 heißt, dass der Page Daemon des Kernels 120 Durchläufe lang versucht die gewünschte Speichermenge zusammenzukratzen. Danach schlägt der OoM-Killer zu. 120 ist die Standardeinstellung mal 10, also zehnmal mehr Durchläufe. Das hilft dem Poudriere-Build. Je öfter man es versucht, umso größer ist die Wahrscheinlichkeit, dass doch noch Speicher freigeworden ist. Da zum Beispiel ein anderer Compiler-Prozess fertig geworden ist.
  • vm.pfault_oom_attempts ist die zweite Ebene. Wenn der Page Daemon keinen Speicher findet, löst er einen Page Fault aus. Nachdem es vm.pfault_oom_attempts Page Faults gab, schlägt der OoM-Killer zu. Das sysctl auf -1 zu setzen, schaltet den OoM-Killer effektiv ab. Das verhindert die Blockade aller Prozesse und das System hakelt gefühlt viel weniger. Es ist völlig legitim das zu machen. Es muss aber klar sein, dass ohne OoM-Killer das System in Deadlocks geraten kann.
Nachtrag: Ich schrieb oben ja schon, dass es Ports gibt, die extremen Speicherbedarf beim Bauen haben. Das wird ganz besonders schlimm, wenn man so irre wie ich ist und zusätzlich noch ALLOW_MAKE_JOBS=yes setzt. Kommen dann mehrere große Ports zusammen, ist selbst mit extrem viel RAM schnell das Ende erreicht. Selbst AWS-Instanzen mit 128 Gigabyte RAM bekommt man damit durchaus noch platt.
 
Zusätzlich hab ich FLANG in den Options deaktiviert. Ich denke das Fortran nicht mehr so weit verbreitet ist (hoffe ich...) :o
Bei dem Flang-Frontend für LLVM 13 handelt es sich um den neuen Fortran 2018 Compiler (aka F18), der den alten Flang 7 ersetzen soll. Die Verbreitung von Fortran nimmt also nicht ab. ;-)
 
@Sickboy Soweit es die Ports betrifft die ich brauche, ist es mir bisher nicht auf die Füße gefallen ;)

Auf dem Raspi 4 hab ich jetzt die Ports gebaut die ich für arm64 brauche. das war nur zum Test. Wie meine Erfahrung aus einem anderen Projekt zeigt bestätigt sich auch hier: Der Raspi4 ist etwa 20 mal langsamer als mein Desktop. llvm13 Desktop 1:05h vs Pi4 ca. 21h. Der BBB ist nochmal Faktor 10 langsamer als der Pi4 (aus dem anderen Projekt). Aber der Pi4 kann auch nativ armv7 ausführen. Das werd ich dann mal als Userland probieren.

Wie gesagt: Mir geht es nur um das Verständnis wie man so ein Gerät unterstützen könnte (wenn man wollte). :)
 
Noch ein paar kleine Fragen zu poudriere:

Ich hab meine Buildjails 131amd64 genannt. Bei der FreeBSD Buildinfrastruktur scheint es so, dass die veröffentlichten Packages nur unter der "FreeBSD-ABI" gebaut sind. Muss ich dann die Jails wenn ein neues Pointrelease kommt auch hochziehen oder kann ich die bei dem Pointrelease lassen? Dass die ABI stabil bleibt, ist ja AFAIK eines der Hauptfeatures von FreeBSD von x.y-RELEASE.

Hier ist mir das bsp. aufgefallen:
oder hier

Die Ordner für pkg sind nur "FreeBSD:12:amd64" oder "FreeBSD:13:amd64".
Heißen die Buildjails bei der FreeBSD Infrastruktur also "FreeBSD:12:amd64" oder "FreeBSD:13:amd64"?
Sind ":" in Jailnamen erlaubt?
Kann ich den Packages Ausgabe Ordner einfach auf den Webserver rsyncen ohne dass ich auf den Namen der Buildjail rücksicht nehmen muß?
 
Ich behaupte mal vorsichtig, dass : in Jailnamen nicht erlaubt sind. Spätestens, wenn da externe Tools ins Spiel kommen, haben sie auch schönes Potential für schwer nachvollziehbaren Ärger. Allerdings ist das kein Problem, denn man muss sowieso einen Weg finden, die Updates atomar zu machen. Also, das entweder die aktuelle Revision oder die neue Revision des Repos genutzt werden, aber zu keinen Zeitpunkt ein Zwischenstand. Denn es macht bösen Ärger, wenn sich während eines laufenden Client-Updates das Repo auf dem Server unnachvollziehbar verändert.

Ich würde es so machen:

  • Poudriere baut die Pakete und sie landen zum Beispiel in /data/poudriere/packages/fbsd_131_amd-latest. Das ist Poudrieres Sicht auf das Repo.
  • Nachdem Poudriere fertig ist, wird das Repo mit rsync umkopiert. Entweder lokal, wenn die gleiche Maschine auch Webserver ist, oder eben remote auf den Webserver. Dabei bekommt das Repo auf dem Ziel einen eindeutigen Namen. Zum Beispiel: rsync -ap --delete /data/poudriere/packages/fbsd_131_amd-latest user@webserver:/data/repos/fbsd_131_amd-latest-20220531-1130
  • Zum Schluss setzt man auf dem Webserver den Symlink auf das Repo um: rm /data/www/FreeBSD:13:amd64 ; ln -s /data/repos/fbsd_131_amd-latest-20220531-1130 FreeBSD:13:amd64.

In dem Moment, wo sich der Symlink ändert, ändert sich auch das Repo für die Clients. Und nur in dem Moment. Sollte das neue Repo ein Problem haben, setzt man den Symlink auf das alte Repo zurück. Wobei man beachten muss, dass pkg auf Downgrades genervt reagiert.
 
Nachdem ich den Raspi/arm64 mit poudriere am laufen habe, wollte ich mich nochmal mit armv7 beschäftigen. Da hab ich was interessantes gefunden: PkgBase . :) Hat damit jemand Erfahrung? Ich denke ich werde mich damit weiter auseinander setzen.



EDIT: Ok... mit 13.0 soll das ja soweit spruchreif sein :)
 
PkgBase hab ich noch nicht zum laufen bekommen aber ich habe die poudriere arm.armv7 Jail gebaut und poudriere baut mir jetzt meine Pakete. Hab auch festgestellt, das man mit poudriere vorkonfigurierte OS Images bauen kann. In allen verschiedenen Ausgabeformaten.

 
Zurück
Oben