Yocto Layer für Apollo

[Ezak]

Hallo zusammen,

ich habe mithilfe von flk (der mithilfe von seifes Yocto Layer einen Layer für Kronos Hardware erstellt hat)
versucht einen Layer für HD2 Hardware (Coolstream Apollo) zu erstellen.

Du finden ist der Layer unter https://github.com/ezak91 wichtig immer im BRANCH Apollo.

Nun wird auch ein lauffähiges Image erstellt, aber starte ich eine binary wie bsp :empty: wird per telnet folgendes ausgespuckt:

Code: Alles auswählen

/var/emu/:empty:: symbol '__ctype_b': can't resolve symbol
/var/emu/:empty:: symbol '__ctype_tolower': can't resolve symbol
/var/emu/:empty:: symbol '__ctype_toupper': can't resolve symbol

Könnt ihr mir helfen die Binarys welche nicht mit Yocto kompillliert wurden auch zum laufen zu bringen?

Viele Grüße
Ezak

[seife]

Warum ein eigener Branch? Branches sind in den yocto/OE-Layers eigentlich immer für das entsprechende release (dylan/daisy/...).
Wieso nicht einfach einen zusätzliche MACHINE definition? man hätte das dann ja in "coolstream-hd1" (die jetzige nevis konfiguration), "coolstream-hd2" (die apollo/kronos(?) immer diese dämlichen codenamen) aufsplitten können. So kann das jedenfalls nie nicht gemerged werden, auch weil die hd1-Teile unnötigerweise rausgelöscht wurden...

Was ist denn "*" für ein Binary? Ist es mit der selben toolchain kompiliert worden?

[Ezak]

Hey Seife,

erstmal danke für deine rasche Antwort.

Sry für das mit dem Branch, aber ich bin was GIT angeht noch nicht lange dabei und lerne auch gerade erst Fachinformatiker,
bin also noch nicht so erfahren, vorallem 0 was Linux und compile angeht.

Habs halt so gemacht, wie flk es auch gemacht hat, dachte wär richtig so.

Das wurde wohl von einem Moderator zensiert, ist wohl eine nicht gern gesehene Binary aus dem Streamboard, welche nicht mit d beginnt, mit welchem Toolchain die compilliert wurde, weiss ich nicht.

Viele Grüße
Ezak

[seife]

Dann diskutiere diese Binary doch im Streamboard, hier sind illegale Topics Tabu. Ende der Durchsage.

[flk]

Warum ein eigener Branch? Branches sind in den yocto/OE-Layers eigentlich immer für das entsprechende release (dylan/daisy/...).
Wieso nicht einfach einen zusätzliche MACHINE definition? man hätte das dann ja in "coolstream-hd1" (die jetzige nevis konfiguration), "coolstream-hd2" (die apollo/kronos(?) immer diese dämlichen codenamen) aufsplitten können. So kann das jedenfalls nie nicht gemerged werden, auch weil die hd1-Teile unnötigerweise rausgelöscht wurden...

Was ist denn "*" für ein Binary? Ist es mit der selben toolchain kompiliert worden?

Hi,

stimmt schon was du sagst, habe ich mir auch schon Gedanken darüber gemacht. Es war für mich halt so erst mal einfacher zu überschauen. Ich habe mir aber schon vorgenommen, dass auf Basis deines Layers irgendwann wieder zusammenzuführen

[Ezak]

Hey seife,

ok vergess die binary, aber ich habe hier auch ein tuxcom welches im original Image läuft und in dem Yocto nicht.
Mir ist klar, dass ich es mit Yocto bauen kann, aber ich würde gerne dass alle Binarys, welche für den a9 compilliert wurden laufen.

Ich bitte dich hilf mir

Viele Grüße
Ezak

[seife]

Da hilft dann wohl nur, die toolchains mit kompatiblen Optionen zu bauen... oder statisch zu linken.

[seife]

stimmt schon was du sagst, habe ich mir auch schon Gedanken darüber gemacht. Es war für mich halt so erst mal einfacher zu überschauen. Ich habe mir aber schon vorgenommen, dass auf Basis deines Layers irgendwann wieder zusammenzuführen

das Problem was du jetzt schon hast ist, das es jetzt 2 Sorten inkompatible *.coolstream.ipk gibt -- gar nicht gut und so nicht zu supporten.

[Ezak]

Da hilft dann wohl nur, die toolchains mit kompatiblen Optionen zu bauen... oder statisch zu linken.

Mh danke, irgendwelche Seiten wo ich mich dazu einlesen kann?

Also einfach uClib Confs Änderungen werden nicht helfen?

Viele Grüße
Ezak

[seife]

Jedes gute Buch über Unix-Systemprogrammierung ist da geeignet, ansonsten irgendwas über Compilerbau und ABIs (dazu habe ich gerade kein Beispiel )

Der Stevens (Advanced Programming in the UNIX Environment): http://www.amazon.de/dp/B00DB3G8KY
Das "Dragon Book" zu Compilern: http://www.amazon.de/dp/B00IZ0FXX6

Ansonsten sind das fortgeschrittene Themen, du müsstest halt in der uclibc schauen, welche Features du an- oder aus machen musst um diese Symbole in der libc drin zu haben. In beiden Umgebungen mit den genau identischen Konfigurationen zu bauen wäre da vermutlich schon die einfachste Lösung.

Warum willst du denn unbedingt die uClibc verwenden und nicht die (e)glibc? Haben die neuen Boxen etwa immer noch so wenig FLASH daß nichts richtiges rein passt? uClibc ist meiner Erfahrung nach öfters mal ein PITA und ich dachte die wäre mit den heutigen FLASH-Größen nicht mehr wirklich in Benutzung...

[flk]

Warum willst du denn unbedingt die uClibc verwenden und nicht die (e)glibc?

Wäre mir auch viel lieber. Ich dachte aber, dass das vermutlich Ärger mit den binären libs von cst gibt, oder ?

[Ezak]

Das dacht ich mir auch, ne Quatsch weil ich keine Ahnung habe was uclibc und eglibc ist und wie man das tauscht, werd mal so ein buch lesen vlt bringts ja was

Benutze ich die selben uClibc confs sagt er iwas von fehlenden Gnu hashes

thx

[seife]

Dann müßt ihr halt Boxen kaufen, wo man keine binären Libs benötigt die es nur für uClibc gibt Der Markt ist ja groß genug, und solange das Zeug gekauft wird hat der Hersteller ja keinen Grund, auf seine Kunden zu hören...

[Ezak]

Sehr hilfreich Seife, ich weiss du hast mit manchen deine Differenzen aber ich hab damit nichts zu tun

[flk]

Der Markt ist ja groß genug

Was dann aber auch wieder ein Problem sein kann ... die Neutrino Community ist leider viel kleiner als der Markt. Damit will ich aber jetzt nicht die Binärstrategie von CST rechtfertigen. Ärgere mich schon auch gelegentlich drüber

[doc]

Na 1GB Flash Chips sind halt immer noch sehr knapp um mit einer halbwegs vernünftigen libc wie der (e)glibc arbeiten zu können. Da ist dann Platz für eine vernünftiges Framework als Basis eben nicht mehr vorhanden Aber wenn man nichts zu tun hat sucht man sich neue Herausforderungen wie alles mit einer uclibc zu bauen die natürlich nicht so viele Funktionen bietet wie eben die (e)glibc. Für die nächsten Boxen und 4GB Flash Bausteinen könnte man dann noch auf die dietlibc wechseln, dort benutzt man auch noch ein vernünftiges VCS wie CVS.

Im Ernst, für mich war das Thema endgültig durch als bekannt wurde das man uclibc benutzt.
Aber wer etwas lesen will zum Thema API Design (mit C++) kann mal hier rein schauen: https://www.elsevier.com/books/api-desi ... 2-385003-4 Da könnte sogar Coolstream noch was lernen, aber ne durchgängige durchdachte API würde ja mit sich bringen das der Code portabel ist ...
Zum grundsätzlichen Einstieg und spätere Fibel kann ich das Buch "Advanced Programming in the UNIX Environment" http://bookshop.pearson.de/main/main.as ... tid=195288 empfehlen, ist aber in englisch und es gibt soweit mir bekannt keine deutsche Übersetzung.

[flk]

Ist auch eine völlig unverständliche Entscheidung für mich gewesen Bei dem mageren nevis Flash noch mit eglibc und dann mit anständig Rechenpower und ordentlich Flashspeicher wird auf uclibc gesetzt.

[seife]

Ezak, sei mir nicht böse, aber mein Interesse, Coolstream in irgendeiner Art zu helfen (und die "Landschftspflege", also die Möglichkeit ordentliche Images zu bauen / bekommen ist zweifelsohne ein Grund, sich für die eine oder andere Box zu entscheiden) ist ziemlich gering nach den Sachen die sie sich geleistet haben und noch leisten.
Wenn du also willst, daß das Zeug ordentlich funktioniert, dann wende dich an Coolstream und die sollen doch den yocto-layer implementieren, der mit ihrem buildsystem kompatibel ist.
Achso, von denen gibt es ja gar kein Buildsystem... Tja. Falsch gekauft?

doc: den Stevens hatte ich schon vorgeschlagen

[Ezak]

Ok schade, aber kann ich verstehen

Danke für die Buchempfehlungen aber das Zeug wird eh schon schwer sein für mich zu kapieren und dann noch auf Englisch

Aber ich schau mich mal um.

Viele Grüße
Ezak

[doc]

doc: den Stevens hatte ich schon vorgeschlagen

Ups, war mir gar nicht aufgefallen. hehe Hatte mir extra die Mühe gemacht den Link zum Verlag zu posten da ich solche Bücher eben nicht mehr bei Amazon hole. Na doppelt hält besser.

Danke für die Buchempfehlungen aber das Zeug wird eh schon schwer sein für mich zu kapieren und dann noch auf Englisch

Besonders das Buch über "Advanced Programming in the UNIX Environment" ist quasi ein Standardwerk und sollte in der Sammlung vorhanden sein. Wirklich gute Bücher sind fast ausschließlich immer nur in Englisch erhältlich, aber wer in einer der Hochsprachen programmieren will kommt um gute Englischkenntnisse nicht herum.

[Ezak]

Cst hat die Kernel Source veröffentlicht