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

[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.

>> 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.

> 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

> 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.

>> 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 ;-)

>> 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).

> 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.
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.

Gruß Roland