Cross-compiler für Coolstream

[seife]

Naja, aber das Fernsehprogramm wird mit Kernel 2.6 auch nicht besser oder bunter. Und der Kernel 2.6 den wir verwenden ist schon so alt, da kann man grad genausogut bei 2.4 bleiben.

[dietmarw]

ich persönlich finde nur diese zweigleisige entwicklung (2.4/2.6) contraproduktiv,
aber evtl. ist das ja nur meine ansicht..

[seife]

Am Kernel wird ja nicht mehr entwickelt. Weder an 2.4, noch an 2.6. Und neutrino ist es ziemlich genau ganz egal, welcher Kernel drunter läuft.
Ja, ich hätte noch ein paar kleine Optimierungen gehabt, die nur auf 2.6 funktionieren, aber die sind nicht so wichtig, dass sie den Aufwand rechtfertigen würden.

[Striper]

Naja, aber das Fernsehprogramm wird mit Kernel 2.6 auch nicht besser oder bunter. Und der Kernel 2.6 den wir verwenden ist schon so alt, da kann man grad genausogut bei 2.4 bleiben.

Warst nicht du selbst hier ein großer Verfechter von Kernel 2.6? Du hast in manchen Aussagen den 2.4er Kernel ja richtig runtergeputzt. Wenn man dann umsteigt kann doch auch sicher eine neuere Kernelversion verwendet werden. Ansonsten sehe ich das ähnlich wie dietmarw. Der Branch Zweig gammelt doch nun schon seit Jahren im CVS rum.

/edit

Zu spät gepostet.

[rhabarber1848]

Wenn man dann umsteigt kann doch auch sicher eine neuere Kernelversion verwendet werden.

Das ist leider nicht so einfach, da ab Kernel 2.6.27 arch/ppc/ in
arch/powerpc/ aufgegangen ist und somit ein großer Teil der
dbox2-spezifischen Kernelpatches anzupassen ist. Von den
binary-only-Modulen (IPBox 2.6.17, Dreambox 2.6.9) ganz zu
schweigen.

Die Kerneldiskussion ist aber eigentlich off-topic, da es hier
um den Coolstream-Support im Tuxbox CVS geht. Afaik läuft
jede Curl-Version auf Kernel 2.4 und 2.6, daher ist wegen
Curl kein Kernel-Update nötig. Ebenso muss afaics Neutrino
nicht angepasst werden. Zumindest kompiliert Neutrino mit
Curl 7.19.x auf der Dbox2.

Warum wird dann generell nicht die neueste Curl-Version verwendet?
Weil libcurl.so in Version 7.19.x fast doppelt so groß ist als in
Version 7.10.x, ohne dass es einen Vorteil bringt. Die Coolstream
hat, afaik, 32 MB Flash, da kommt es auf ein paar KB mehr oder
weniger nicht an, auf der Dbox2 hingegen schon.

[Striper]

Danke für die Ausführungen. Dann ist es wohl besser wenn weiterhin Zweigleisig gefahren wird. :)

[MPC823]

Ist glibc-2.3.6 mit gcc4 kompilierbar?

wizig die Frage kann sogar diesmal ich beantworten, nach meiner kleinen openwrt exkursion.

Dort kann man das alles auswählen (make menuconfig) . Was nicht ging war mit einem gcc 4.2.x die glibc 2.3.6 zu bauen mit der glibc 2.7 ging es aber für die 2.3.6 kann man aber einen gcc 4.1.x auswählen, dann baut es wieder. Eine Version dazwischen gibts auch aber die hatte ich nicht probiert.

es lag wohl daran das beim 4.2 sehr starke Optimierungen eingeflossen sind und die glibc version 2.3.6 dafür nicht kompatibel ist.

Das wollte ich Dir mal noch sagen schau Dir doch mal das openwrt an wie das gemacht ist da sind ein paar ganz gute Ansätze drin bei der auswahl wie man was baut wenn es dann auch oft an der einen oder anderen stelle dann klemmt weils beim bauen hängen bleibt.

Gruss Martin

[bosmann]

Weil libcurl.so in Version 7.19.x fast doppelt so groß ist als in Version 7.10.x...

Meine libcurl.s0.4:

[rhabarber1848]

Meine libcurl.s0.4:

Das glaube ich nicht so ganz, ich habe heute auch noch
einmal gebaut:

Curl 7.10.x 115 KB
Curl 7.19.6 230 KB

[bosmann]

Meine libcurl.s0.4:

Das glaube ich nicht so ganz, ich habe heute auch noch
einmal gebaut:

Curl 7.10.x 115 KB
Curl 7.19.6 230 KB

Ursprünglich ist bei mir auch so groß aber wenn ich ein Paar Binaries strippe, wird curl so klein.

guckst du hier

[rhabarber1848]

Ursprünglich ist bei mir auch so groß aber wenn ich ein Paar Binaries strippe, wird curl so klein.

Die von mir ermittelten binary-Größen sind durch das make target
flash-neutrino-squashfs-all für die Dbox2 entstanden, mklibs.py
hat also seine Arbeit getan, ebenso wurde alles gestrippt.

[Striper]

wittinobi hat für die Coolstream ein Build-Script veröffentlicht. Evtl. kann das wer brauchen.

Ist eigentlich in Planung das man Coolstream Images aus dem Tuxbox CVS heraus bauen kann soweit es bisher möglich ist?

http://rapidshare.com/files/312973651/c ... -script.sh

[dietmarw]

mal sehen wie weit er kommt

[seife]

Vor allem, weil ich schon Makefiles habe, wo man nur noch "make neutrino" tippen muss

[rhabarber1848]

--with-curlversion=old/current

committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/1589
http://article.gmane.org/gmane.comp.vid ... x.scm/1590

[dietmarw]

wittinobi hat für die Coolstream ein Build-Script veröffentlicht. Evtl. kann das wer brauchen.

Ist eigentlich in Planung das man Coolstream Images aus dem Tuxbox CVS heraus bauen kann soweit es bisher möglich ist?

http://rapidshare.com/files/312973651/c ... -script.sh

in seinem script existiert leider kein fehlerhandling, alle errors werden ignoriert und übergangen.
das ergebnis wird oft nicht brauchbar sein.

[rhabarber1848]

Ist eigentlich in Planung das man Coolstream Images aus dem Tuxbox CVS heraus bauen kann

Meinerseits ja, nur scheine ich damit im Moment allein auf weiter Flur zu sein.
Außerdem habe ich keine Coolstream, deshalb ist meine Motivation nicht sehr groß.

[mb405]

hab das buildscript mal probiert.
irgendwie baut der den crosscompiler hier schon mal garnicht.
kann aber auch an meinen system liegen
kubuntu.
obwohl tuxbox-cvs images einwandfrei gebaut werden

ps ne coolstream hab ich daliegen. ich mag nur keine fertigen images.

[dietmarw]

bisher wurden bei mir z.b. in step5 die libs nicht automatisch entpackt (vorhanden waren die archive)
läuft jetzt weiter..

edit: step 17 muss auf 0.7.2 prüfen
läuft jetzt weiter..

edit: durchgelaufen ist das script jetzt, aber ich bin noch auf der suche nach dem output *g

[dietmarw]

Vor allem, weil ich schon Makefiles habe, wo man nur noch "make neutrino" tippen muss

in einem sauberen verzeichnis laufen die aber unter opensuse 11.0 bisher nicht durch

bzw. wenn /opt/cross leer ist auch nicht (vorher newcross)

[rhabarber1848]

Vor allem, weil ich schon Makefiles habe, wo man nur noch "make neutrino" tippen muss

... und ich fürchte, es wird sehr schwer, Dich zu überreden, diese Sachen ins Tuxbox CVS einfließen zu lassen, richtig?

Im Moment wäre eigentlich nur ein neues target neutrino-coolstream nötig, mit passenden Abhängigkeiten
und dem SVN checkout des Codes (analog zu eglibc), damit es mit dem Tuxbox CVS gebaut werden kann.
Die libs, der cross compiler und viele 3rd-party Tools sind ja schon alle vorhanden, was für Dich den Aufwand
ebenfalls reduzieren würde. Ich habe gesehen, dass Du gestern make targets für strace/gdb/e2fsprogs/busybox
& Co. erstellt hast, das wäre nicht nötig gewesen, wenn Du mit dem CVS arbeiten würdest

Ich habe einfach die Befürchtung, dass sich die Entwicklerzweige ungewollt nie mehr zusammenfinden werden,
wenn wir nicht an diesem Punkt darüber diskutieren und eine, wie auch immer geartete, Entscheidung treffen.

[seife]

Vor allem, weil ich schon Makefiles habe, wo man nur noch "make neutrino" tippen muss

... und ich fürchte, es wird sehr schwer, Dich zu überreden, diese Sachen ins Tuxbox CVS einfließen zu lassen, richtig?

Ja. Weil ich es für einen Irrweg halte, möglichst alles mit dem tuxbox-CDK erledigen zu wollen. Deswegen ist es mir die Arbeit nicht wert.

Sowohl für die Tripledragon als auch für die Coolstream reichen eine Handvoll einfacher Makefiles (kein automake/autoconf etc., keine 500 configure-optionen) aus, und man kann dan problemlos extern gebaute Compiler etc. verwenden, oder sich auch einfach ein debian auf die Box installieren und halt das neutrino-Binary dazukopieren.

Ich sehe ein, dass man für Boxen mit begrenzter Hardware, insbesondere begrenztem Flashspeicher (dbox/alte dreamboxen) das tuxbox-CDK benutzt, aber für alle anderen limitiert es einem nur unnötig.

Die libs, der cross compiler und viele 3rd-party Tools sind ja schon alle vorhanden, was für Dich den Aufwand
ebenfalls reduzieren würde.

nicht wirklich, denn jede Änderung im tuxbox-CDK ist extrem aufwändig, wegen den tausend "if maschine_x" Fällen. Und dann will ich mal wieder nen Einzeiler testen, warte aber ne halbe Stunde drauf, weil jemand unbedingt den neuesten 2.4.xx.xxx-Kernel einspielen musste und deswegen die toolchain und alles neu gebaut wird Das ist nicht "reduzierter Aufwand".
Ausserdem ist mein Plan ja, dass ich den ganzen Krust von einer fertigen Distribution installiere, also nicht selbst bauen muss.

Ich habe gesehen, dass Du gestern make targets für strace/gdb/e2fsprogs/busybox
& Co. erstellt hast, das wäre nicht nötig gewesen, wenn Du mit dem CVS arbeiten würdest [/code]
Doch, denn die busybox ist halt anders konfiguriert. Ausserdem war 90% einfach copy'n'paste der tripledragon. Ich hatte mir auch überlegt, ob ich die coolstream-makefiles mit in die TD-makefiles mit einbauen sollte, eben weil sie momentan zu einem Grossteil identisch sind, aber rein gefühlsmässig glaube ich, dass es langfristig einfacher ist, wenn die getrennt sind. Es gibt einfach zuviele leicht unterschiedliche Sachen (teilweise weiss ich auch gar nicht sicher, ob die unterschiedlich sein müssen oder nicht, aber ich will mir nicht auch noch diese Fehlerquelle erschliessen, erstmal baue ich möglichst gleich wie Lucian )

Ich habe einfach die Befürchtung, dass sich die Entwicklerzweige ungewollt nie mehr zusammenfinden werden,
wenn wir nicht an diesem Punkt darüber diskutieren und eine, wie auch immer geartete, Entscheidung treffen.

Ich denke, dass das CDK relativ wenig mit der Entwicklung zu tun hat. Wichtig ist, was unter apps/ liegt, der rest ist nur Dekoration.

[PT-1]

Hi,

kann man jetzt eigentlich schon ein komplettes funktionierendes Image fuer die Coolstream vom CVS bauen?

PT-1

[seife]

natürlich nicht, da der code für die Coolstream nicht im CVS ist.

[mrvica]

bin zufällig auf diese Seite gestossen, könnte vielleicht hilfreich sein
https://sman.informatik.htw-dresden.de/ ... tool_chain

mrvica