Hallo zusammen,
versuche gerade noch mal neu zu kompilieren mit exakt den Einstellungen, mit denen es vor 10 Tagen (am 6.04.) noch problemlos geklappt hat. Nun gibt es Fehler und es werden keine Images erzeugt.
Immer etwas wie ‚prepare-target failed‘
Pastebin: Link
Auf wie vielen Kernen hast du gebaut?
Für mehr als einen Kern läuft es bei mir auch überhaupt nicht mehr. Man kann nur noch auf einem Kern bauen, weil das herunterladen der benötigten Pakete sonst nicht funktioniert. Soweit ich es verstanden habe, liegt das an den OpenWRT-Servern und der Tatsache, dass das Gluon die Daten nicht puffert.
Mit -j1 läuft es bei mir gut durch.
Danke, das werde ich probieren. Ich hatte auf 8 Kernen gebaut. Weißt du zufällig, warum es mit den OpenWRT-Servern Probleme gibt? Gibt es da eine Quelle zu dieser Info? Beziehungsweise, wie lange das andauern wird?
Noch eine Verständnisfrage: was ändert es an den OpenWRT-Servern, wenn ich mit mehr als einem Kern baue? Das erschließt sich mir nicht. Kann man Gluon vielleicht irgendwie beibringen, die Daten zu puffern?
Es hängt an irgendwelchen Downloads die während des Kompilierungsvorgangs erfolgen müssen. Das ist nicht so ganz sauber parallelisiert. Meiner Meinung nach fehlen da einfach ein paar wait-Anweisungen im make-file, habe es mir aber noch nicht im Detail angeschaut. Denn mit einem Kern läuft es bei mir immer.
Habe es jetzt mit einem einzelnen Kern probiert. Leider bricht er dabei auch ab.
Das ist komisch ;). Fehlermeldung?
Immer noch 'prepare-target failed`
Die Ausgabe von „-j1“ ist aber geordneter. Eventuell sieht man dann mehr Details. Ich hab es auch noch nicht so raus, da Ursachen zu erkennen, in dem Mehrkernbuildlog oben habe ich nichts gefunden.
Ich baue noch mal und poste dann mal das Single-Core-Log.
@collimas
das bauproblem ist oft genereller art,
make würde irgendwann später versuchen auf Dinge zuzugreifen die noch nichtmal runtergeladen sind - es enthält schlicht keine/kaum Logik um Dinge zu priorisieren, bzw auszusitzen. Das hat weniger was mit den (manchmal) stark ausgelasteten openwrt Servern zu tun (die aber die Zeitschraube derb nach oben drehen können bei einem Download)
zum Vergleich, bauen auf existierendem Zeug dauert bei mir 5 min,
mit Download und ALLEM das letzte mal 78 min.
so, zu den logs, wir rufen make in der Regel mit tee auf , damit lässt sicher der output von stdout und stderr bequem in eine log datei leiten.
Zusätzlich noch V99 (für sehr sehr sehr gesprächiges make)
in der einfachen Variante : make foobar V99 2>&1 | tee make.log
wobei foobar alle deine anderen Parameter wären
# so ähnlich benutz ich das
# könnte man so direkt auch benutzen
branch=experimental
release=v2016.1.3
basedir=$PWD
time make V=99 \
GLUON_TARGET=ar71xx-generic \
GLUON_BRANCH=$branch \
GLUON_RELEASE=$release \
GLUON_OPKG_KEY=$basedir/gluon-opkg-key \
GLUON_OUTPUTDIR=$basedir/gluon/output/$branch \
GLUON_IMAGEDIR=$basedir/gluon/output/$branch \
GLUON_MODULEDIR=$basedir/gluon/output/modules 2>&1 | tee make_$branch_$release_$(date +%y%m%d_%H%M).log
# danach existiert eine make_experimental_v2016.1.3_foobar_20160401_2342.log
# die könnte man dann beser durchsuchen und Fehlermeldungen posten
# ( Warning ist da ein gutes Suchwort )
Das ist ein Running Gag, der uns bis ans Ende der Tage begleiten wird.
Je nach Tageszeit oder Mondphase braucht man auch bei „nur ein Kern“ 2-8 Versuche, bis die Toolchain komplett ist, also wirklich alles rechtzeitig heruntergeladen werden konnte (und eben keine Timemouts etc) den Weg verstellen.
Danke euch allen, im Moment scheint es wieder zu gehen, auch mit 8 Kernen.
irgendwie ist das unbefriedigend. Eigentlich soll mein Buildscript nach jedem Durchlauf (ich baue für mehrere Community-SSIDs) aufräumen und keine „Altlasten“ aus vorherigen Läufen recyceln. Scheinbar ist das aber notwendig, wenn man nicht solche Überraschungen erleben will.
Es hört sich nicht so an, als ob das das Problem gewesen wäre.
Zumindest liest sich das Log anders.
Mal eine Frage von jemandem der sich zwar auf der Konsole gut zurecht findet, aber noch nie etwas selber kompiliert hat: Warum muss da überhaupt was runtergeladen werden? Ich dachte immer man besorgt sich den Source in einem Tarball, startet das entsprechende Make Script und das wars. Warum ist denn in den Sourcen nicht alles enthalten was man braucht? Sorry für die Noob Frage:-)
Was für Sourcen?
Gluon ist kein Programm, das ist eine Build-Environment.
Du musst immerhin einen kompletten Linux-Kernel bauen.
Und ein Haufen GNU-Utities (compression, lighttpd)
Und eine Busybox.
Und der Wifi-Krempel
Und LUA/LUCI und was noch so zu OpenWRT gehört.
Und das alles für einen Prozessor, der (meist) nicht der des Build-Systems ist.
Es muss also auch noch ein Crosscompiler gebaut werden, um die Sachen zu bauen.
genauer: Mehrere Crosscompiler, für jede Architektur (AR7k, MIPS, …) einen.
Und noch ein Haufen Zeug, den ich jetzt vergessen habe.
Das in ein Tarball zu packen: Könnte man machen… aber nicht sinnvoll.
Weil der Tarball dann einfach viel zu groß wäre und Zeug enthält das man nicht zwingend braucht?
Mir ist vollkommen egal wie groß solch ein Tarball wäre. Hauptsache ALLES Notwendige ist drin und es gibt nicht ewig Theater beim Bauen weil Quellen langsam/nicht verfügbar sind.
Gibt es eine Liste ALLER benötigter Komponenten?
Du hast aber schon bemerkt, dass es sich bei Gluon um (mindestens) 3 Ebenen kaskadierte GITs handelt.
Also z.B. „Gluon holt openwrt, openwrt holt Linuxkernel, Linuxkernel holt C-Compiler“
Wenn Du alles notwendige drin haben willst, dann brauchst Du ja die crosscompiler nicht nur für „mips auf AR71xx“, sondern auch für „AR71xx auf ARM“ etc… Soll ja Leute geben, die Gluon nicht auf AMD64 bauen.
Das heisst, den Crosscompilerpart würde man x^y-fach brauchen.
Nicht zu vergessen, dass viele Leute vermutlich weder gluon auf Raspberry bauen, noch Openwrt für XEN benötigen.
Schon verstanden. Ich stelle halt nur die Integrität der Kaskaden in Frage. Da ist einfach sehr viel, wo es haken kann.
Bei uns kam letztens die Idee auf, einfach mal alles zu spiegeln, was das braucht und dann über die hosts-Datei die Zugriffe lokal umzuleiten.
Hat das schon mal jemand probiert? Mich nervt es zunehmends, dass man so oft kompilieren muss, bis es endlich mal klappt.