Keine echte Hilfe, ich weis aber ...

Jemand hat sich schon eine komplette Entwicklungsumegbung auf der Dream gebaut zum Compilieren und Linken, du müßtest also nicht das Rad neu erfinden.

Das Ganze würde mich zwar auch interessieren, aber ohne die ganzen libraries zum linken wird das nicht viel bringen und dann wird das image wohl so gross das du es nur mehr auf einer Multiboot Partition auf CF Karte auspacken kannst (na ja die gehen jetzt zwar schon bis zu 500MB groß), oder du mußt die libs wieder über NFS mounten,...

Gruss
thowi

Zitat

Original von Ticalian
Vielleicht hat ja einer eine Idee.

I tried to reproduce your error, but on my system the error came later, during the install stage. I would guess that I came a little bit further because I'm using the .../site/mipsel-linux file from the dev branch of OpenWorks, the one in the dreambox branch is quite outdated. See the end of DM7025 CVS Build auf AMD64 (SuSE) for patches.

I also see some small differences in the gcc_4.1.0.bb file between the dev and dreambox branches (some more patches are applied in the dev branch), but I haven't tested to see if these are significant or not. You could try to copy the dev branch files to the dreambox branch and see if they make a difference.

Hi,

wo kann man den das package, das der von Thowi erwähnt user gebaut hat, downloaden? Hab's nirgens gefunden.

Gruß Mamba

du musst schon die suchfunktion bemühen und den originalthread finden (und ich bin nicht mal 100% sicher obs in diesem Board war), aber es war für privatgebrauch und kein downloadlink dabei, du müßtest also in den bettelmodus gehen ...

Probiers mal mit compiling on dreambox suchen, oder ähnlichem.

Zitat

Jemand hat sich schon eine komplette Entwicklungsumegbung auf der Dream gebaut zum Compilieren und Linken, du müßtest also nicht das Rad neu erfinden.

Ja gut ich habe die Entwicklungsumgebung für dei Dream portiert. Allerdings für die 7000er. Da dort das komplette CVS noch mit Makefiles in einer Crossumgebung realisiert ist das doch ein Unterschied zum open embedded (mit monotone) etc.

Es ist nicht einfach damit getan ein paar Änderungen in diversen Files zu machen. Normalerweise ist es ja auch nicht von Nöten einen Compiler in das Image einzubinden. Somit ist das CVS auch dafür nicht vorbereitet. Es bedarf also einiger Änderungen und Patches. Die Fehler kommen evtl. davon, dass du versuchst einen Crosscompiler in dein Image einzubinden. Damit wirst du aber auf der Box keinen Spass haben, denn der Crosscompiler funktioniert nur auf dem PC. Was du tun musst nennt sich "Canadian Crosscompile" (na nicht ganz) und sieht vereinfacht wie folgt aus.

1. Baue Binutils für BUILD=x86 und HOST=ppc
2. Baue Stage1 crosscompiler für BUILD=x86 und HOST=ppc ohne Verwendung von glibc.
3. Baue glibc mit Stage1 cross-gcc für HOST=ppc
4. Baue Stage2 (finished) Crosscompiler für BUILD=x86 und HOST=ppc mit glibc für HOST=ppc.

Das sind in etwa die Schritte, die auch im CVS gemacht werden. Nun hast du den Crosscompiler der Codes für ppc erzeugt und auf deinem PC (x86) läuft. Damit baust nun einen localen Compiler der auf deinem TARGET=ppc läuft und Codes für das TARGET=ppc erzeugt.

Also der ganze Kram wie oben wiederholst, nur das diesmal nicht mit dem gcc deiner x86 Machine compiliert wird, sondern mit dem Crosscompiler. Quasi ein BUILD=x86, HOST=ppc, TARGET=ppc. -> Baue einen Crosscompiler mit dem du einen Compiler für die Dream bauen kannst.

Es ist also ein Unterschied, auf welcher Platform ein Compiler lauffähig ist und für welche Platform er Codes erzeugt (übersetzt -> compiliert). gcc eignet sich aber dafür am besten, da der gnu compiler für die meisten Platformen portierbar ist.

Das fertige Package gibt es übrigens unter h**p://imageonhd.info zum downloaden + Anleitung. Erfordert allerdings eine Registrierung im Forum.
In wie weit der ganze Kram (dazu gehört wesentlich mehr als nur gcc und die binutils) auf der 7020 funktionieren, habe ich nicht getestet. DXler hat dort im Forum aber die ganze Sache auf seiner 7020er zu laufen.

cheers

Zitat

Wegen des hohen Speicherbedarfs installiere ich die Pakete auf der Festplatte.
Ist ideal, so braucht man nach einem Imagewechsel den ganzen selbstgebauten Spass nicht neu zu installieren und konfigurieren.

Hatte ich anfangs auch so gemacht. Aber warum nicht gleich nach /usr.
Zumindest lässt sich ein /usr Verzeichnis ja irgendwie immer sinnvoll auf der Box mounten. Warum /usr ? Weil beim Bauen mit dem besagtem configure Script immer meist nur in den Standart Pfaden /usr, /bin, /usr/local usw. nach den benötigten Tools gesucht wird. Setzt man seinen gcc + Tools gleich in /usr an, ersparrt einem das im Nachhinein ne Menge unnötigen Arbeit bei der Configuration zum Bauen diverser Tools. Manche Sourcen akzeptieren auch keine anderen Suche Pfade trotzt richtig gesetzter Umgebungsvariablen. Also hilft dann nur noch patchen.

Ich habe meine Packages alle nach /usr installiert. Gepackt wird dann der ganze Kram auf USB oder CF und als /usr gemountet. Alternativ kann ich auch das ganze Package von jedem Images aus als chroot betreten und von dort aus wird der gcc etc. immer in /usr gehandelt. Ist wesentlich besser als vorweg den Pfad des gcc irgendwo in /hdd festzulegen. Ist nur ein Typ um etwas Zeit zu sparen.

cheers

Im Multiboot 6* gibt es jetzt ein Multiboot Exchange directory das auf Harddisk, USB oder per default auf CF Karte liegen kann und je nach vorhandenem Platz auch beliebig gross sein kann. Die Idee ist das man dort auch schön Plugins, sowie Sachen die aus der Ornithologie stammen hinlegen kann und diese dann entsprechend verlinken - also für die plugins ein /media/mbX/Extensions das dann von /usr/lib/python/Plugins/Extensions verlinked wird.

Man sollte das aber nur für sachen machen die wenn sie dann im Image fehlen (z.B. CF Karte draussen) keine negativen auswirkungen haben.

Eine ganze Entwicklungsumgebung (Compiler, Libraries, *.h files,...) die man dann mit einem Link von dort ins Image einbinden könnte hätte dann schon seinen Reiz. Und ich würde auch gerne ein kleines Compiler Plugin basteln damit man es komfortabler beim installieren und verwenden des Ganzen hat.

Also bastle mal schön weiter, ich hätte auch gute Verwendung dafür
....

PS: Sachen auf die Festplatte legen ist zwar immer der kleinste gemeinsame Nenner und auch OK, aber es geht eben auch hübscher.

Gruss
thowi

Zitat

Was hälst Du denn von der Idee, GCC und co. so zu kompilieren, dass diese Pakete ihr "Root-Verzeichnis" in "/usr/local" haben?

Und "/usr/local" würde man dann per symbolischen Link auf die Festplatte legen.

/usr/local ist ne gute Sache, zählt zumindest zu den Standart Suchpfaden. Aber bitte keine Symlinks. Ich bin ein echter Hasser von Symlinks in diesem Zusammenhang, denn es bringt nur unnötig Ärger. Besser ist allemale "mount -o bind Quelle Ziel". Also erstelle einen Ornder local unter /usr und mounte den ganzen Kram auf beliebigem Medium dorthin. Ist ein Befehl und alles in einem Abwasch am richtigen Platz.

Zitat

Und ich würde auch gerne ein kleines Compiler Plugin basteln damit man es komfortabler beim installieren und verwenden des Ganzen hat.

Also das müsstest du mal erklären, wie das funktionieren soll. Geht es um das reine Compilieren ist man doch allemale schneller mit einer Crossumgebung bzw. via telnet auf der Dreambox. Warum ich die Entwicklungsumgebung gebaut habe war zum einem der Grund, dass man damit einige Sachen local compilieren kann, die nur mit viel Aufwand und Änderungen der Sourcen in einer Crossumgebung zu verwirklichen waren. Beispiel Perl und auch noch Python soweit ich das noch in Errinnerung habe. Ich kann mir aber beim besten Willen nicht vorstellen, das ich auch nur die geringste Lust dazu hätte via FB irgendwas auf der Box zu compilieren.

cheers

na ja einen compile Befehl über dei FB abzusetzen wäre schon etwas pervers.

Ich hatte eher dran gedacht das man mit dem Plugin das ganze runterlädt, auspackt wo man möchte (harddisk, Multiboot Exchange Partion,...) entsprechend verlinked (oder vermountet wenn es Dir lieber ist). Die ganzen Pfad und environmentvariablen anpasst,...).

Dann muss wohl wer ein ipkg draus bauen,... (was ich mir eh schon länger anschauen wollte, und bei einer Entwicklungsumgebung wären die Dependencies schon recht heftig,...)

Aber mir ist schon klar das ein Entwickler der weis was er tut das alles gar nicht braucht

Aber eines habe ich aus so Sachen wie dem Cronmanager plugin gelernt - solange du es nicht hübsch verpackst benützt es keiner, und deswegen habe ich ja auch z.B. begonnen das automount plugin zu entwicklen (und blöde mount Befehle müßte doch wirklich jeder hinkriegen, oder ?).

Gruss
thowi

Achso, dann habe ich das natürlich falsch verstanden. So macht das mit dem Plugin natürlich Sinn.

Warum hübsch verpacken? Wer es haben will, soll es nehmen wer nicht, der wird nicht wissen was ihm entgeht. Ich bin sowieso der Meinung, wer auf der Dream nicht wenigstens ein wenig mit der Konsole umgehen kann lernt die Vorzüge der Box nie kennen, es sei denn er hat sich die Box nur wegen den Laufvögeln gekauft.

Bezüglich Abhängigkeiten wirst du auf der Dreambox immer Probleme haben. Das liegt mit unter daran, daß du nie vorweg weißt auf welchem Image welche Funktionen aus den libs gestrippt wurden. So bleibt dir entweder ultimatives probieren oder gleich den ganzen Kram statisch zu linken, damit das Tool auf jedem Image rennt. Dadurch sinkt aber schnell die Performance und der freie Speicherplatz.

Ich habe lange überlegt wie ich das bewerkstelligen könnte bezüglich der Crossumgebung, bin dann aber zum Schluß gekommen, daß man für volle Kompatibilität das mitgelieferte Development Image nutzt, bzw. die Tools und libs aus dem Image + das Develpackage in einer chroot Umgebung verpackt und von beliebigem Image mountet. Bei mir laufen die meisten Prozesse sowieso in dieser chroot, denn ich habe das nervige libs tauschen in jedem Image satt, das manchmal auch zu Problemen führen kann. So kann ich beispielsweise Perlskripte, Pythonscripte wie auch das mklibs.py auf der Box von beliebigem Image aus laufen lassen.
Übrigens baue ich auch auf diese Weise aMule auf der Box.

cheers

Oder du machst mit Multiboot 6.3 eine bis zu 512MB grosse Imagepartition in der Du es installierst und hast dann genug (!) Platz auf /usr/local

PS: Ich wußte doch das das Feature zu was gut sein würde Image Partitionen für Multiboot in fast beliebiger Größe zu machen

PPS: Jetzt muss ich auch noch meine alten c Programme rauskrammen um zu testen, aber neue Spielzeuge sind immer wilkommen, also nochmals DANKE !

Gruss
thowi

na ja das aktuellste Multiboot 6.3 findest Du im I*D Board (wo man auch Träume hat und Images herkommen die mit Blue screen booten über die hier nicht gesprochen wird) oder in fast jedem Dreamboard gibts in der 7025er section entsprechende Downloads dafür bis uns musicbob erlöst (?!)

Vorteil ist relativ einfach:

Wenn das Image auf der Cf Karte liegt braucht die Harddisk nicht ständig laufen, schneller ist es dadurch auch, und wenn mans am laufen hat kann mans entsprechen sichern durch wegkopieren des ganzen images, sprich wenn man neue Versionen, plugins, settings, skinns ausprobiert kann man schnell wieder zurück ohne neu zu flashen.

Und das Limit vom Flash ist dann natürlich auch weg, und weil du dadurch memory sparst (kein jffs2 vom Flash) hast du auch mehr zum Complieren zur verfügung (wirs sehen was passiert wenn du was großes compilierst - willkommen swapfile !)

Und mehrere Images ausprobieren und booten kann man dann natürlich auch.

PS: Und den link zu deinen ipk files solltest du auch dort im Board gleich posten (z.B. e2 plugin section), ich denke da hätten auch andere viel Freude damit.

Gruss
thowi

Hi,

die Loesung den gcc einfach auf die HDD zu packen und dann in einer abgesicherten Umgebung zu starten, wäre schon genial.

Gruß Mamba