[Fli4l_dev] Programm mit SCR / fbr unter Ubuntu 16.04 übersetzen geht nicht

[Helmut Backhaus]

Am 22.05.2016 um 19:08 schrieb Roland Franke:
> Hallo,
>
>>> Kann es sein das du den Build jetzt unter Ubuntu Server 14.04.4 mit dem
>>> vorherigen Versuch mit Ubuntu 16.04 LTS verwechselst?
>
>> Nun, da habe ich mich vielleicht nicht aussagekräftig ausgedrückt!
>> Mit in *keinem Fall* meine ich weder auf der 16.04 noch auf der 14.04
>> kann ich die Toolchain übersetzen. Was dann noch dazu kommt, ist dass
>> ich auf der 16.04 nichts übersetzen kann!
>> Auf der 14.04 eben nur die Toolchain nicht!
>
> Hier ist das "Baut nicht" einfach zu wenig detailreich.
> Es kommt immer auf die exakte Stelle an, an welcher der Build dann
> fehlt schlägt.
> Als Beispiel:
> Wenn du sagst: Dein Auto springt nicht an.
> Kommen (Als Beispiel) folgende Möglichkeiten in Frage:
> Kein Sprit, falscher Sprit, Benzinpumpe kaputt, Sicherung kaputt, Zünd-
> Anlassschalter kaputt, etc.
> All diese Punkt sind jedoch pauschal als "Spring nicht an" gegeben.
>

Das ist mir auch klar, da ich aber jeweils als ich es versucht habe die 
Logdateien hochgeladen hatte, bin ich davon ausgegangen das das reicht. 
Denn es hat ja auch niemand nach weiteren Angaben oder Daten gefragt.

Aber ich kann gerne die Fehler noch einmal provozieren und dann die 
nötigen Angaben / Daten liefern. Was wird gebraucht?

>>> Zum anderen könntest du eventuell einmal testen, wenn du den
>>> toolchain mit dem Parameter J=1 (Vor dem ./fbr-make) zusätzlich
>>> versuchst zu bauen?
>
>> Das es da Unterschiede gibt habe ich auch schon festgestellt, z.B.
>> geht das übersetzen (in ein frisches Verzeichnis) mit 4 Kernen
>> langsamer wie mit einem. Ich habe die Maschine jetzt auf 2 gesetzt,
>> dass geht wohl am schnellsten.
>
> Ist auch in Abhängigkeit von der Festplatte. Wenn da die Daten nicht
> schnell
> genug kommen, stockt der parallel-Build dann dort.
>

Ok, das kann ich nicht so ohne weiteres prüfen, aber so ganz langsam ist 
meine Konstellation nicht! Das sind LVM's auf einem Raid 5, da geht 
schon was! Z.B. das starten einen HVM DomU (MintMate 17.3) ist in 10 
Sekunden da, die PV DomU's sind noch schneller.

>> Was mir auch aufgefallen ist, ist dass das FBR immer einen Prozessor
>> mehr nutzen möchte als vorhanden ist.
>
> Das ist auch normal. Der "zusätzliche Prozessor" übernimmt die Verteilung
>

OK, dann macht das Sinn.

>> Also so:
>> FBR_BASEDIR=~/.fbrtest2 FBR_ARCH=x86_64 J=1 ./fbr-make toolchain
>
>> OK, ich stoße das mal so an, wird eh 2 Stunden dauern :-(
>
> Ok. Mal schauen was dabei raus kommt. Aber wie oben beschrieben.
> Nur der exakte Fehler (Fehlerstelle) bringt die Information zur Ursache.

Dann hätte ich auch die Ausgabe des Laufs und das dazugehörige Logfile 
geliefert! Aber es hat ja funktioniert und da habe ich gedacht, dass die 
Ausgabe des Laufs reicht.

>
>>> Mit dem J=1 setzt du den build auf die Benutzung von nur einem core
>>> (Auch wenn dein Prozessor 4 oder 8 haben sollte) fest.
>>> Mit dieser Variable konnte ich den toolchain auch unter MintMate 17.3
>>> bei mir lokal bauen.
>
>> Soll ich das hier auch mal genauso testen?
>
> Das machst du doch bereits ;-)
>

Jane, jetzt schon, es läuft gerade. Und ich glaube hier geht das irgend 
wie schneller. Kann aber auch nur subjektiv sein ...

>>> Was dann wieder auf ein Problem mit einer Abhängigkeit untereinander
>>> im FBR hindeuten würde.
>>>
>
>> Also in dem Builroot selbst, nicht im Fli-Teil?
>
> Buildroot und Fli-Teil sind das gleiche. Bei Fli4l wird nur eine eigene
> Konfiguration von Buildroot mit den nur hier verwendeten Paketen verwendet.
> Der Toolchain ist jedoch Grundbasis von allen zum bauen der Pakete auch für
> die jeweiligen Architekturen (Für was ja das Buildroot konzipiert ist).
>

OK, dass war mir so nicht klar. Ich dachte immer das das ein spezielles 
Buildroot für das Fli-Projekt ist!

>> Ich auch, dafür werde ich jetzt erst mal den 14.04.4 Server nutzen!
>> Danke noch mal für Deine ausdauernde Unterstützung!!!
>
>> Vielleicht finden wir ja noch etwas um dieses Problem zu lösen!
>
> Vermutlich wird bei Fli4l immer eine ältere Variante des Host-System zum
> bauen das beste sein, da bei Buildroot die Entwicklung immer weiter
> geht und somit (Als Beispiel !!) ein aktuelles Host-System erst mit Build-
> root 2017-01 komplett unterstützt wird.

Damit kann ich gut leben! Auf eine DomU mehr kommt es nicht an!

> Zusätzlich wird bei Fli4l ja nicht im kompletten Entwicklungszweig von
> Buildroot gearbeitet (So hat die 3.10 ja noch Buildroot 2014.11).
> Zu diesem System konnte damals noch niemand wissen wie die
> Entwicklung auf dem Host (Dein Rechner) weitergeht um die kommenden
> Eigenheiten neuerer Programme einbinden zu können.
>

Das ist klar, aber ich habe das immer auf meinem "normalen 
Arbeitsplatzrechner" gemacht und habe mir dazu nie wirklich Gedanken 
gemacht. Warum auch es hat ja immer funktioniert! ;-)
Das man das so nicht machen sollte / kann habe ich ja nun gelernt!

....

So, und nun ist es passiert Der Buildlauf von der Toolchain auf der 
MintMate17.3 ist schief gegangen!

Gemacht habe ich das in einem 4.0 src!

Aufruf -->
FBR_BASEDIR=~/.fbr40test01 FBR_ARCH=x86_64 J=1 ./fbr-make toolchain

Hier die Daten:
Laufausgabe -->
http://pastebin.com/t0cMwM9a

Logdatei -->
http://www.file-upload.net/download-11603987/build.log.html

Wird noch etwas gebraucht?


-- 
Gruß,
Helmut