Allgemeine Probleme und Antworten

[max_10]

nein es liegt daran, wie YYLTYPE geändert wird beim Kernel bauen, das entfernen der Zeile ist nicht der richtig weg,
es muss ein extern vor YYLTYPE yylloc; in scripts/dtc/dtc-parser.tab.c eingefügt werden.

[vanhofen]

Ich hatte das gestern nicht groß getestet. Ich dachte, was für Buildroot gut ist, kann für uns nicht schlecht sein.

[vanhofen]

Neuer Versuch. https://github.com/neutrino-images/ni-b ... 011472283a

[Kittybua1210!]

Neuer Versuch. https://github.com/neutrino-images/ni-b ... 011472283a

Wollte mich nochmals bedanken weil das mit der bin also das make neutrino-full-update ist echt top und Ruck zuck alles ! Super Tipp war das ! So einfach kann das Leben sein ! Lua API ist auch jetzt auf 1.96 und die version 2128 !Danke echt klasse von dir @vanhofen !

P.s. nicht wundern bei der version nach Update schaut auf Lua API bzw Neutrino nicht Version es passt weil habe eine neue gebaut vorgestern da ist die Version größer als die alte aber Lua api etc älter so Beispiel nach Update bin:

Version : 4.10.95.112 hat API 1.95 und 2122 neutrino
Version : 4.10.89.111 hat API 1.96 und 2188 neutrino

Also nicht auf die Version Nummer schauen nach bin Update sondern auf das andere ! Wenn ich was falsches sage bitte ausbessern danke @vanhofen bin selber erst drauf gekommen da es mich gewundert hatte ! bin Datei ist also tip top ! Danke alles super und schnell !

[Janus]

Fix erfolgreich.
Hat durchgebaut!

[max_10]

nun ist der fix wider kaputt
https://github.com/neutrino-images/ni-b ... fb4a1ee507
vu+ boxen fehlen.

[vanhofen]

Die Solo4k ließ sich damit nicht kompilieren. Ich hatte den den Kanal voll und alle VUs ausgeschalten.
Bei dir geht das wohl bei der Solo4k?

[max_10]

Wenn es jetzt so bleibt, können alle die GCC Version 10 im System haben keine VU Box mehr bauen.

nein es liegt daran, wie YYLTYPE geändert wird beim Kernel bauen, das entfernen der Zeile ist nicht der richtig weg,
es muss ein extern vor YYLTYPE yylloc; in scripts/dtc/dtc-parser.tab.c eingefügt werden.

Der Fehler lautet ja multiple defs yyloc, daher schrieb ich ja oben schon ändern in scripts/dtc/dtc-parser.tab.c,
wenn die Kernel Version noch andere Einträge, mit YYLTYPE yylloc hat und sed das ändert kann das schon gegen den Wand laufen.
Mit der einen Änderung, wird dann auch gebaut, wenn im System GCC < 10 => 10 vorhanden ist.

[vanhofen]

OK, Danke. Dritter Versuch.

PS: Bua, der Danke-Knopf ist kein Lesebestätigungs-Knopf.

[Janus]

Duo4K:
Baut immer noch durch!

[seife]

<gebetsmühle>Wenn der system-Compiler oder im system installierte Pakete das Ergebnis einer Crosskompilation beeinträchtigen, dann ist das Buildsystem "broken beyond repair"</gebetsmühle>



Sag ich ja nur seit über 8 Jahren

[vanhofen]

Wie fixt man es denn dann richtig?

[Miky]

Ach seife, vielleicht darf ich das nach glaube ich fast 20 Jahren Neutrino Zugehörigkeit einfach mal schreiben : warum schreibst du nicht, wie es zu fixen wäre? Und komm mir bitte nicht damit, dass du diese Boxen nicht hast, denn dann wäre dein Post eh nicht zielführend. Das begleitet mich nun schon so lange, ist eigentlich ein immer wiederkehrendes no go.

[seife]

Die Kurze Antwort: man nimmt eine Buildumgebung, die dafür sorgt, daß das nicht passieren kann, weil sie mit selbsttests prüft ob sog. "host contamination" auftritt. z.B. openembedded.

Wenn man das nicht will, dann muss man das eigene Buildsystem so anpassen daß es das eben auch macht. Dazu gehört mindestens (aber bestimmt habe ich einige vergessen):

• -nostdinc & co beim kompilieren nutzen, wo irgend möglich oder den crosscompiler gleich so bauen, daß der default-include-pfad irgendwo in /invalid oder so liegt
• alle tools wie pkg-config, autoconf, automake, cmake, ... in einer cross-variante bauen, daß sie eben nicht in den normalen system-Pfaden nach includes, configs, wasauchimmer schauen, sondern nur in den fürs crosscompiling vorgesehenen Pfaden
• output aller buildjobs mitloggen (verbose mode natürlich) und hinterher nachschauen ob nicht doch irgendwo im falschen Pfad "geschaut" wurde

Hm, mehr fällt mir grad nicht ein, ich dachte die Liste wäre noch länger gewesen. Aber das Problem ist: schon die letzten 2 Punkte bedeuten Scheisse viel Arbeit. Ich hatte damals angefangen, aber dann festgestellt, daß der Aufwand wesentlich größer war, als sich in openembedded einzuarbeiten, was ich dann stattdessen gemacht habe. "Never looked back"

Ansonsten ist das Minimum was man machen sollte: Lösungen wie "ja, da musst du noch xyz-devel installieren" nicht zu akzeptieren, weil *immer* wenn ein crosscompileproblem auftritt, das durch "xyz-devel" gelöst wird, dann hat der buildjob an der falschen Stelle nach den xyz-devel Headern gesucht (oder xyz.pc, und wenn der von der falschen stelle gelesen hat, dann stehen da auch falsche sachen drin).
Beim Cross bauen ist es eben nicht egal wo der Header herkommt. Ich hab mal ein paar Tage nach einem mysteriösen Segfault gesucht, bis ich drauf gekommen bin daß der curl-header vom Host genommen wurde, von einer neueren Version war, wo sich eine Datenstruktur in der Größe geändert hatte. Ich sag mal so. Die Ursache zu finden ist für Fortgeschrittene

Ich hab, als ich noch die "falsche" Methode benutzt habe, öfters mal versucht, auf einem minimalsystem zu bauen. Also nur das installieren, was man zum crosstool bauen benötigt (und halt make etc). Wenn dann plötzlich sachen nicht zu bauen gehen, dann deutet das darauf hin, daß ein notwendiges Tool fehlt. Damals hatte ich dazu ein paar snapshots von minimalinstallierten VMs, heute würde ich vermutlich docker-Container dafür nehmen.

[max_10]

Der Hauptgrund warum der Fehler auftritt liegt aber auch an >= GCC 10

gcc 10 will default to -fno-common, which causes this error at link
time:
(.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here

This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern".

ab Kernel 4.14 im April 2020 wurde dort auch die Einträge bearbeitet °Remove redundant YYLOC global declaration°.
Selbst openembedded-alliance-core Patch die ganzen alten Kernel, damit dann dort durch gebaut werden kann.

[flk]

https://lkml.org/lkml/2020/4/1/1206

[jokel]

https://git.keyedlimepie.org/voidanix/a ... 836e37e34e
https://git.keyedlimepie.org/voidanix/a ... cripts/dtc

[vanhofen]

Jungs, die gleichen Links wurden doch schon mehrfach gepostet und auch im Buildsystem erfolglos getestet. Das konntet ihr doch alle mitverfolgen. Uns jetzt einfach nur kommentarlos immer wieder die gleichen URLs vor die Füße zu werfen, ist nicht sehr zielführend.

[TangoCash]

Na pack doch die entsprechenden Kernel-Patches dazu.

[flk]

Jungs, die gleichen Links wurden doch schon mehrfach gepostet und auch im Buildsystem erfolglos getestet. Das konntet ihr doch alle mitverfolgen. Uns jetzt einfach nur kommentarlos immer wieder die gleichen URLs vor die Füße zu werfen, ist nicht sehr zielführend.

Das dieser Patch schon gepostet wurde, muss ich übersehen haben. Wegen kommentarlos .... naja. Der Patch hat eine commit message die das Problem ja wirklich gut beschreibt. Das war halt was ich damals gemacht und was bei mir geholfen hatte. Die Zeile komplett aus scripts/dtc/dtc-lexer.l entfernen.

"which means the declaration is completely redundant and can just be dropped."

Führen ja auch immer mehrere Wege nach Rom. Den Kernel mit '-fcommon' zu bauen könnte ja auch helfen.