Cross-compiler für Coolstream

[rhabarber1848]

Hi,

folgender Patch ermöglicht es, den cross-compiler für die
Coolstream-Box aus dem Tuxbox CVS heraus zu bauen:

EDIT: Patch ist im CVS

Dieser Patch beeinflusst nicht das Bauen von Dbox2-Images,
Dream- und IPBox habe ich nicht getestet, sollten aber laufen.

Dazu gibt es die neue Option --with-boxtype=coolstream
und die üblichen make targets, also "make bootstrap".

Die Vorgehensweise beim Erstellen des cross-compiler und
der zugehörigen eglibc ist 1:1 von cross-tool-ng kopiert
worden, wie es auch von Coolstream eingesetzt wird.

Im Patch anbei sind einige compile-Patches, hauptsächlich
include-Ergänzungen, da irgendwo zwischen gcc-3.4.6 und
gcc-4.3.2 die Header-Organisation geändert wurde.
Darüberhinaus sind die gcc und gmp-Patches von crosstool-ng
enthalten, die auch von Coolstream genutzt werden, sowie
ein weiterer upstream-Patch, der das Kompilieren von
libFLAC ermöglicht.

Was geht:
- cross-compiler komplett
- viele libs
- stand-alone-Tools wie links, busybox, esound

Was nicht geht:
- Kernel
- tuxtxt, tuxcal, tuxmail (Houdini hat Coolstream-spezifische Patches dafür)
- Neutrino
- Enigma
- manche libs, wie libcommoncplusplus, libffi
- und vieles mehr

To-Do
- libfreetype-2.3.9 für Coolstream

[Striper]

Also geht leider so ziemlich alles nicht was interessant ist. ^^ Aber danke für die Mühe rhabarber!

Naja die Hoffnung stirbt zuletzt... ;)

[rhabarber1848]

Also geht leider so ziemlich alles nicht was interessant ist.

Das wird auch so bleiben, bis die Coolstream-Leute ihrer GPL-Pflicht nachkommen.

[seife]

Die Frage, die ich mir stelle, ist: warum sollte man ein gut funktionierendes Tool (crosstool-ng) im tuxbox-cdk duplizieren (und das CDK dadurch noch komplexer und undurchschaubarer machen)?

Es sollte doch problemlos möglich sein, mittels "--with-toolchain=PATH" die per crosstool gebaute toolchain zu benutzen. Wenn das *nicht* funktioniert, sollte man lieber das fixen.

Ein Grund, warum ich für die TD mit meinen eigenen Makefiles baue ist, dass das tuxbox-CDK unnötig komplex ist, und damit die Fehlersuche unnötig kompliziert.

[rhabarber1848]

@seife: Für Deine Frage gibt es kein klares Ja oder Nein.

Du nutzt das Tuxbox CVS mit externen Compilern,
ich bevorzuge den Ansatz, dass das Tuxbox CVS
alles notwendige beinhaltet, was zum Kompilieren
nötig ist, da ich nicht von crosstool-ng oder anderen
externen Tools abhängig sein möchte. Für beide
Varianten gibt es Vor- und Nachteile, eine allgemeine,
klare Präferenz ist für nicht erkennbar.

Wenn beides funktioniert, sehe ich keine Probleme,
da mein Patch sich hauptsächlich auf
cdk/make/bootstrap.mk auswirkt, die Komplexität
wird nur unwesentlich gesteigert. Im Gegenteil,
ich hatte Mühe, die "if !USE_FOREIGN_TOOLCHAIN"-Blöcke
so anzupassen, dass mein Coolstream-Patch funktioniert.
So gesehen, ist IMHO der USE_FOREIGN_TOOLCHAIN-Code
komplizierter als mein Coolstream-Patch

Beides kann aber IMHO nebeneinander gleichwertig im
Tuxbox CVS existieren.

Der Vorteil der Erzeugung der cross-compiler im Tuxbox CVS ist,
dass der erzeugte Code nicht abhängig von lokalen Compilern,
deren Revisionsständen und Patches ist, ein definierter Zustand also.

PS: smiley hinzugefügt

[rhabarber1848]

Ein Grund, warum ich für die TD mit meinen eigenen Makefiles baue ist, dass das tuxbox-CDK unnötig komplex ist, und damit die Fehlersuche unnötig kompliziert.

Das Erstellen eines TD-Images aus dem Tuxbox CVS heraus
steht auch noch auf meiner To-Do-Liste

[rhabarber1848]

Wer den cross-compiler aus dem Tuxbox CVS mit dem Original
vergleichen möchte, hier mein Skript für das Coolstream CDK.
Es benötigt Bash v4, wer noch mit Bash v3 arbeitet, muss die
entsprechende sed-Zeile rausnehmen:

Code: Alles auswählen

#!/bin/sh

COOLDIR=$HOME/tuxbox/cool
PATH=$COOLDIR/crosstool-ng/bin:$PATH
rm -rf $COOLDIR
for i in svn crosstool-ng build download; do
	mkdir -p $COOLDIR/$i
done
cd $HOME/tuxbox/cool/svn
svn co --no-auth-cache --username coolstream --password coolstream http://www.coolstreamtech.de/coolstream_public_svn
cd $COOLDIR/svn/coolstream_public_svn/CROSSENVIROMENT/crosstool-ng-1.3.2

# remove if bash v3 is present
sed -i "s/^\/bin\/bash\/\^GNU bash, version 3\\\./\/bin\/bash\/\^GNU bash, Version 4\\\./" configure

./configure --prefix=$COOLDIR/crosstool-ng
make install
cd $COOLDIR/build
sed -e 's#\(CT_LOCAL_TARBALLS_DIR=\).*#\1'\""$COOLDIR/download"\"'#g' \
    -e 's#\(CT_PREFIX_DIR=\).*#\1'\""$COOLDIR/build/\${CT_TARGET}"\"'#g' \
	$COOLDIR/svn/coolstream_public_svn/CROSSENVIROMENT/crosstool-ng-configs/config-cx2450x-1.3.2 > \
	.config
ct-ng build

[mb405]

ich fände es auch praktisch alles in einer umgebung zu erstellen.
mal abwarten, ob die coolstream nicht ne totgeburt wird mangels sourcen

[rhabarber1848]

mal abwarten, ob die coolstream nicht ne totgeburt wird mangels sourcen

... und solange hat mein Patch im CVS nichts zu suchen.

[mb405]

genau. wenn mal sourcen kommen, könte man nochmal nachdenken drüber.
so viel anders wird da ja nicht sein. es draht sich doch wie ich gelesen hab nur um hardwaretreiber freigabe.

[rhabarber1848]

es dreht sich doch wie ich gelesen hab nur um hardwaretreiber freigabe.

So wird es kolportiert, Coolstream kann dennoch schon
jetzt den Neutrino-Sourcecode freigeben, auch wenn
er mangels Hardware-Treiber-includes nicht kompilieren
wird. Interessant ist der Code schon jetzt allemal.

Meine Meinung, bis zum Beweis des Gegenteils, ist,
dass sich Coolstream hinter dem Chipsatzhersteller
und dessen Weigerung zur Veröffentlichung von Header-
Dateien versteckt, um NeutrinoHD nicht rauszugeben.
Dazu ist Coolstream aber lt. GPL verpflichtet.

Gut, dass ich im Moment keine HD-Box brauche und
mit meiner Dbox2 voll und ganz zufrieden bin

[mb405]

dito.
aber die 500mhz reizen schon

[rhabarber1848]

@seife: Spricht etwas dagegen, die gcc4-Patches aus meinem
Patch schon jetzt ins CVS zu committen? Sie stören gcc3 nicht.

[seife]

Ich habe da keine Meinung zu (ich habe es mir auch nicht angeschaut). Längerfristig auch für die dbox mit gcc 4.x zu bauen hätte sicher einige positive Auswirkungen auf die Codequalität ;-)

[rhabarber1848]

Längerfristig auch für die dbox mit gcc 4.x zu bauen hätte sicher einige positive Auswirkungen auf die Codequalität ;-)

Dazu habe ich einige Fragen, deren Beantwortung
ich schon länger vor mir hergeschoben habe.
Vielleicht kannst Du aus dem Stehgreif was dazu sagen:

Ist glibc-2.3.6 mit gcc4 kompilierbar?
Wenn nein, funktioniert glibc > 2.3 mit Kernel 2.4?
Das hängt wohl mit linuxthreads zusammen, da
NPTL nicht auf Kernel 2.4 läuft.

EDIT: Ich habe gerade glibc-linuxthreads-2.5.tar.bz2
gefunden, vielleicht gibt es damit mehr Chancen?

[rhabarber1848]

folgender Patch ermöglicht es, den cross-compiler für die
Coolstream-Box aus dem Tuxbox CVS heraus zu bauen:

coolstream_cdk.diff

Patch wegen CVS-Änderungen aktualisiert

[rhabarber1848]

Im Patch anbei sind einige compile-Patches, hauptsächlich
include-Ergänzungen, da irgendwo zwischen gcc-3.4.6 und
gcc-4.3.2 die Header-Organisation geändert wurde.

Dieser Teil ist nun im CVS:
http://article.gmane.org/gmane.comp.vid ... x.scm/1484
http://article.gmane.org/gmane.comp.vid ... x.scm/1485
http://article.gmane.org/gmane.comp.vid ... x.scm/1486
http://article.gmane.org/gmane.comp.vid ... x.scm/1487
http://article.gmane.org/gmane.comp.vid ... x.scm/1488
http://article.gmane.org/gmane.comp.vid ... x.scm/1489
http://article.gmane.org/gmane.comp.vid ... x.scm/1490
http://article.gmane.org/gmane.comp.vid ... x.scm/1491
http://article.gmane.org/gmane.comp.vid ... x.scm/1493
http://article.gmane.org/gmane.comp.vid ... x.scm/1493

Coolstream-Patch aktualisiert: coolstream_cdk.diff

[gugu]

Ab Heute sind Neutrino sourcen Public.

[rhabarber1848]

Ab Heute sind Neutrino sourcen Public.

Das sieht nicht schlecht aus
Der cross-compiler-Patch ist jetzt im Tuxbox CVS.

[rhabarber1848]

Es stellt sich nun das Problem unterschiedlicher library-Versionen,
nicht nur bei freetype (2.0.9 vs. 2.1.4 vs. 2.3.9), sondern auch
bei curl (7.10.1 vs. 7.19.6).

Die einfache Lösung wäre, die verwendete Version vom Boxtyp
abhängig zu machen, das ist allerdings unflexibel. Es gibt bereits
User, welche die aktuelle Curl-Version auf anderen Boxen einsetzen.

Deshalb schlage ich neue cdk/configure-Optionen (was auch sonst )
vor, im Stile von --with-curlversion=old/current. Konkrete Versions-
nummern möchte ich nicht verwenden, da ansonsten die Komplexität
zu hoch wird. Wenn der Boxtype coolstream gesetzt wird, wird zudem
automatisch --with-curlversion=current gesetzt, sofern die Option
--with-curlversion nicht angegeben wird. Alle anderen Boxen nutzen
weiterhin Curl 7.10.1, sofern --with-curlversion nicht gesetzt ist.

Hier mein Patchvorschlag: EDIT: Patch ist im CVS

[Striper]

Oder doch mal Kernel 2.6 zum Standard machen bei der DBox. Dann sollte es doch drin sein die gleichen Library Versionen zu nutzen?!

[rhabarber1848]

Oder doch mal Kernel 2.6 zum Standard machen bei der DBox.

Ich bin dagegen, da Kernel 2.6 um einiges größer ist als 2.4.

Dann sollte es doch drin sein die gleichen Library Versionen zu nutzen?!

Das eine hat mit dem anderen nichts zu tun.

[Striper]

Dann sollte es doch drin sein die gleichen Library Versionen zu nutzen?!

Das eine hat mit dem anderen nichts zu tun.

Ist es nicht so das bestimmte neuere Libs nur unter Kernel 2.6.x laufen?

[rhabarber1848]

Ist es nicht so das bestimmte neuere Libs nur unter Kernel 2.6.x laufen?

Ja, nur glaube ich nicht, dass das auf Curl und Freetype zutrifft.

[dietmarw]

Ich bin dagegen, da Kernel 2.6 um einiges größer ist als 2.4.

aber soweit ich weiß hat sich noch keiner von den "kernelspezis" mal intensiv um eine größenoptimierung gekümmert?
denn wenn er nur noch "ein wenig" größer wäre, würde dieser kleine nachteil auf jedem fall
von dem großen vorteil des wegfalls der ganzen 2.4/2.6 differenzen wettgemacht werden.

und eine handvoll kernelspezis sind ja hier vertreten..

edit:
vor fast genau zwei jahren hat das einer derjenigen auf jeden fall mal gesagt
http://forum.tuxbox-cvs.sourceforge.net ... af#p346830