Cross-Compiler für die Box

[andreas.koch]

Hallo zusammen!

Ich habe mal einen Cross-Compiler für Box erstellt. Die damit compilieren Programme sollten (hoffentlich) ohne chroot-enivornment auf der Box laufen. Habe das bis jetzt allerdings nur mit zwei Hello-World-Programmen getestet (eins in C und eins in C++).
Falls jemand interesse daran hat, gibts da vorläufig den Cross-Compiler (http://www.ping.de/sites/karlmarx/mips-m740av-toolchain.tar.bz2) (vorläufig, weil ich mit den knapp 35 MB eigentlich mein Webspace von 20 MB überschreite).

Das Host-System des Compilers ist i686-linux (bei mir Debian-Sarge).
Zur Benutzung: einfach das Archiv entpacken und den Path entsprechen auf das enthaltene Verzeichnis mips-m740av-toolchain/bin setzen. Mit mips-linux-uclibc-gcc bzw. mip-linux-uclibc-g++ kann man dann wie gewohnt Programme übersetzen.

Ach so, die Firmware meiner Box ist noch eine orginale 1.12.1, was aber eigentlich kein Problem darstellen sollte, da sich die Versionen der Libraries in den neueren Version der Firmware meines Wissens nicht geändert haben.

Ich hoffe damit kann jemand was anfangen (habe hier bis jetzt noch keinen fertigen Cross-Compiler gefunden). Ich selbst habe im Moment nicht genug Zeit um damit zu experimentieren.

Grüße

Andreas

[hagalulu]

hallo andreas,

wäre super wenn du das auch noch in die wiki eintragen könntest. ich denke ein vernünftiger chross-compiler kann echt weiterhelfen.

hagalulu

[andreas.koch]

Hallo hagalulu,

werde ich ich die Wiki eintragen, sobald ich weis ob der Compiler weites gehend vernünftig läuft. Beim erstellen mußte ich nämlich einiges patchen, damit er überhaupt lief (in der uClibc 0.19.19 fehlt nämlich noch ziemlich viel).

Ich denke auch das ein vernünftiger Cross-Compiler weitehelfen kann, nur sollte er dann auch sauber laufen, was man mit einen Test mit Hello-Worlds aber noch nicht sagen kann.

Grüße

Andreas

[grisu]

Hallo Andreas,
habe den Cross-Compiler gerade heruntergeladen
und mein erstes Programm erfolgreich übersetzt.
(simples Programm, das /proc/net/dev auswertet und auf der Console ausgibt)
Ich werde weitere Programme testen.


Gruss
Ulrich

[Lescho]

Hallo Andreas,

ich habe mir jetzt auch deine cc-toolchain gezogen. Leider bin ich damit nicht ganz so erfolgreich :(. Den dropbear-0.44 habe ich wie folgt übersetzt :

./configure --host=mips-uclibc-linux-gnu --prefix=/home/lescho/mips-m740av-toolchain/usr/local --disable-zlib
make

Entsprechende Links in der ~/mips-m740av-toolchain/bin (mips-uclibc-linux-gnu-... -> mips-linux-uclibc-...) habe ich gesetzt da sich ein configure-script beschwert hatte das es das Zielsystem nicht kennt. Leider bekomme ich folgende Fehler beim ausführen vom dropbear:
dropbear: can't load library 'mp_exch'

Vielleicht könntest du ja mal schreiben was Du noch geändert hast - schließlich hast Du ihn ja zu laufen gebracht. Auch bei anderen Programme bekomme ich häufig Fehler beim ausführen z.B der mini_httpd. Das liegt ja wahrscheinlich an der uClibc-0.9.19. Wenn Du oder jeder andere hier noch ein paar Tips zum übersetzen mit dem Cross-Compiler habt wäre ich Euch echt Dankbar.

Gruß,
Dennis

[andreas.koch]

Hallo Dennis,
--host= muß das Ausgangssystem sein (i686-linux). --target=mips-linux-uclibc (für die Box). Manchmal muß man auch CC=mips-linux-uclibc-gcc vor das ./configure setzten. Der Path auf den Compiler muß entsprechend gesetzt sein.
Ich hatte vorher noch die zlib übersetzt und in der Toolchain installiert.
Dann habe ich noch in dem Makefile die Variablen AR LD RANLIB und STRIP angepaßt .
Da steht noch ein File options.h, da habe ich den Path auf /dev/urandom gesetzt.
Im File config.h, habe ich #define HAVE_OPENPTY und #define HAVE_PTY_H auskommentiert. (Funktionierte damit auf der BOX nicht)

Gruß

Andreas

[Lescho]

...
--host= muß das Ausgangssystem sein (i686-linux). --target=mips-linux-uclibc
...

Ja so habe ich das auch zuerst gedacht bis ich beim dropbear ./configure --help aufgerufen habe, das sagt folgendes:
...
--host=HOST cross-compile to build programs to run on HOST [BUILD]
...
oder verstehe ich da was falsch?
Danke auf jeden Fall für die schnelle Antwort - werde das morgen noch ein wenig testen.

Gruß,
Dennis

[Lescho]

Hallo,

leider komme ich immer noch nicht weiter. Z.B habe ich die zlib-1.1.3 (die Version benutzt Siemens auch) übersetzt. Wenn ich Sie als share-lib übersetze laufen die Beispiel-Programme example/minigzip ohne Probleme, wenn ich aber zlib.a verwende und statisch binde bekomme ich bei beiden einen Sementation-Fault. Also muss der Fehler wohl in übersetzung der Library liegen. Als Test habe ich dann nochmal einzeln minigzip mit der zlib.a von Siemens übersetzt - ebenfalls Seqmentationfault. Da stimmt doch irgendwo was nicht.

Wenn ich beim dropbear wie von Andreas empfohlen ./configure --host=i686-linux --build=mips-linux-uclibc --with-zilb=../zlib-1.1.3 aufrufe bekomme ich folgendes:

checking for i686-linux-gcc... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether make sets $(MAKE)... yes
No $CFLAGS set... using "-Os -W -Wall" for GCC
checking build system type... Invalid configuration `mips-linux-uclibc': system `uclibc' not recognized
configure: error: /bin/sh ./config.sub mips-linux-uclibc failed
[/code ]
Deshalb hatte ich links in ~/mips-m740av-toolchain/bin gesetzt der Form mips-linux-uclibc -> mips-uclibc-linux-gnu-... ist glaube ich auch der Standard ARCH-(unknown)-OS-(gnu) ist aber auch nicht so wichtig. Das ganze liefert dann:
[code]checking for i686-linux-gcc... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether make sets $(MAKE)... yes
No $CFLAGS set... using "-Os -W -Wall" for GCC
checking build system type... mips-uclibc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for i686-linux-ar... no
checking for ar... ar
checking for i686-linux-ranlib... no
checking for ranlib... ranlib
checking for i686-linux-strip... no
checking for strip... strip
checking for i686-linux-install... no
checking for install... install
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether __UCLIBC__ is declared... no
checking for crypt in -lcrypt... yes
checking for deflate in -lz... no
configure: error: *** zlib missing - install first or check config.log ***
Wie man sieht versteht das configure-script die Sache hier genau falsch herum(deshalb schlägt der deflate-test auch fehl weil die zlib ja für mips und nicht für x86 compiliert wurde). Also andersherum probiert :
./configure --host=mips-uclibc-linux-gnu --build=i686-linux --with-zlib=../zlib-1.1.3

checking for mips-uclibc-linux-gnu-gcc... mips-uclibc-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether mips-uclibc-linux-gnu-gcc accepts -g... yes
checking for mips-uclibc-linux-gnu-gcc option to accept ANSI C... none needed
checking whether make sets $(MAKE)... yes
No $CFLAGS set... using "-Os -W -Wall" for GCC
checking build system type... i686-pc-linux-gnu
checking host system type... mips-uclibc-linux-gnu
checking for mips-uclibc-linux-gnu-ar... mips-uclibc-linux-gnu-ar
checking for mips-uclibc-linux-gnu-ranlib... mips-uclibc-linux-gnu-ranlib
checking for mips-uclibc-linux-gnu-strip... mips-uclibc-linux-gnu-strip
checking for mips-uclibc-linux-gnu-install... no
checking for install... install
checking how to run the C preprocessor... mips-uclibc-linux-gnu-gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether __UCLIBC__ is declared... yes
Using uClibc - login() and logout() probably don't work
checking for crypt in -lcrypt... yes
checking for deflate in -lz... yes
Enabling zlib
Disabling PAM
Using openpty if available
checking for library containing openpty... -lutil
Enabling syslog
checking shadow.h usability... yes
checking shadow.h presence... yes
checking for shadow.h... yes
Using shadow passwords if available
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/tcp.h usability... yes
checking netinet/tcp.h presence... yes
checking for netinet/tcp.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking for unistd.h... (cached) yes
checking crypt.h usability... yes
checking crypt.h presence... yes
checking for crypt.h... yes
...

Now edit options.h to choose features.
Einen Blick ins Makefile geworfen, alles schon perfekt konfiguriert inkl. ar,ranlib usw. Kleiner Auszug:

prefix=/usr/local
exec_prefix=${prefix}
bindir=${exec_prefix}/bin
sbindir=${exec_prefix}/sbin

CC=mips-uclibc-linux-gnu-gcc
LD=mips-uclibc-linux-gnu-gcc
AR=mips-uclibc-linux-gnu-ar
RANLIB=mips-uclibc-linux-gnu-ranlib
STRIP=mips-uclibc-linux-gnu-strip
INSTALL=install
CFLAGS=-I. -I$(srcdir)/libtomcrypt -Os -W -Wall
LIBS=$(LTC) $(LTM) -lutil -lz -lcrypt
LDFLAGS=-L../zlib-1.1.3

So dann habe ich noch -I../zilib-1.1.3 zu den CFLAGS hinzugefügt und make durchlaufen lassen, bis auf 2 '... unused' Warnungen alles OK.
Noch mal zum testen file dropbear aufgerufen:

dropbear: ELF 32-bit MSB MIPS-I executable, MIPS, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Files rüberkopiert ausgeführt und

sh-2.05# dropbear
dropbear: can't load library 'mp_exc
erhalten. Ich bin echt am verzweifeln. Ist ja nicht nur der dropbear s. zlib-statisch (und das kann man host/build/target überhaupt nicht verwechseln). Kleine Test-Programme laufen zwar aber spätestens wenn es ans linken mit Bibliotheken geht, funktioniert nichts mehr. Bin für jede Hilfe Dankbar. Vielleciht kann mir ja auch mal jemand ne Prüfsumme von dem ganzen Toolchain-Paket schicken.

Gruß,
Dennis

[andreas.koch]

Hallo Dennis,

Der zweite Lauf des Configure-Scripts sieht gut aus.
Aus irgendeinem Grund scheint der dropbear sich nicht gegen eine seiner eigenen Libraries zu linken, denn mp_exc* sind Funktionen der Library libtommath, aus den dropbear Sourcen.
Ich vermute irgendwo einen Build-Rest, aus einem vorhergegangen Compilerlauf (make erkennt nicht für welches System eine Lib übersetzt wurde).
"make clean" sollte vor make ausreichen.
Wenn nicht, würde ich es mit make distclean und anschließend einem neuen configure-Lauf probieren.

Gruß

Andreas

[Lescho]

Hallo Zusammen,

nachdem ich überhaupt keinen Ausweg mehr wusste habe mal die Binaries(example/minigzip) der zlib-1.1.3 von Siemens auf die Box geschoben und ausgeführt. Die sind auch beide in einem Segmentation-Fault geendet. Da bin ich doch sehr stutzig geworden. Als FTP habe ich den in Gnome eingebauten benutzt, also ftp://192.168.0.x in die Adreesleiste und dann via drag'n'drop. Das war auch schon der ganze Fehler.(Keine Ahnung warum - vielleicht liegts am ASCII-Mode). Sehr fies, da es bei kleinen Files(HelloWorld usw.) funktioniert hat - mal ganz abgesehen von von Fehlern wie "can't load library 'mp_exc'" (Da kommt man ja nie auf einen Übertragungsfehler).
Naja, lange Rede gar kein Sinn mit Commandline-FTP funz alles Prima.

Gruß,
Dennis.

[andreas.koch]

Hallo!
Habe eine neue Version des Cross-Compilers (ca. 28 MB) (http://www.ping.de/sites/karlmarx/m740av_toolchain_clean.tar.bz2) erstellt.
Wesentliche Änderungen:

binutils 2.16.1
gcc-3.3.6
Patches von uclibc.org wurden auf die binutils und den gcc angewandt.
erzeugt durch die Patches wesentlich kleineren Code
locale- und wchar-Support wurde in der uClibc aktiviert (aber Vorsicht: ist ungetestet, in der Version der uClibc nur sehr eingeschränkt vorhanden und war nur mit einigen Eingriffen von mir (insbesondere in der libstdc++) zum Compilieren zu bewegen.)


Grüße

Andreas

[Lemmi]

Habe eine neue Version des Cross-Compilers (ca. 28 MB) (http://www.ping.de/sites/karlmarx/m740av_toolchain_clean.tar.bz2) erstellt.
Download fertig.
Aber ansehen, dass werde ich in den nächsten Tagen nicht tun.
Die FW-Umstellung hat schon wieder viel zu viel Zeit gekostet.

[andreas.koch]

Download fertig.
Aber ansehen, dass werde ich in den nächsten Tagen nicht tun.
Die FW-Umstellung hat schon wieder viel zu viel Zeit gekostet.
Schon klar! Bin im Moment etwas am expermentieren.
Die größen Unterschiede bezogen auf die beiden Compiler-Versionen.
Mit dem alten habe ich z.B. dein stdin2tcp nicht unter 67584 Bytes bekommen,
mit dem neuen geht es 10120 Bytes runter. (in vielen Fällen produziert das Flag -O3 übrigens kleineren Code; sogar als -Os)
Wie hast du das den auf 14412 Bytes mit dem alten Compiler geschafte :confused:

Grüße

Andreas

[Lemmi]

Wie hast du das den auf 14412 Bytes mit dem alten Compiler geschafte :confused:

Dank deiner tools:


name="stdin2tcp"
opt="-O3 -Wall -DDEBUG=0"
mips-linux-uclibc-gcc $opt -o $name $name.c
m740av-siemens-strip -s $name

[andreas.koch]

Dank deiner tools:


name="stdin2tcp"
opt="-O3 -Wall -DDEBUG=0"
mips-linux-uclibc-gcc $opt -o $name $name.c
m740av-siemens-strip -s $name

schon merkwürdig! der strip aus binutils 2.13 scheint die Binaries kleiner zu machen als der aus der 2.15er (beide ungepatchte Versionen). Wundert mich aber das das funktioniert. Hatte soviele Versions Probleme, dass ich immer die Versionen benutzt, mit denen auch kompiliert wurde. Siemens-Tools mit der 2.15er strip funktionierte nämlich gar nicht.
Naja im Grunde sollte ich froh sein, dass der Compiler überhaupt läuft ....

Grüße

Andreas

[Install]

Hallo Leute,

ich würde gerne mal das "Hello World" Programm auf der Box nachvollziehen. Leider habe ich nur Programmiererfahrung mit Visual Studio und Windows. Kann mir vielleicht jemand auf die Sprünge helfen wie man am besten vorgeht und welche Programme man benötigt?

Vielen Dank,

Install

[andreas.koch]

ich würde gerne mal das "Hello World" Programm auf der Box nachvollziehen. Leider habe ich nur Programmiererfahrung mit Visual Studio und Windows. Kann mir vielleicht jemand auf die Sprünge helfen wie man am besten vorgeht und welche Programme man benötigt?

Ein C/C++ Compiler ist vollständig in dem tar.bz2 (siehe Link oben) für Linux enthalten. Ansonsten braucht man halt nur einen Editor, und telnet Zugang zur Box.
Bin mir aber nicht sicher was du vorhast/erwartest?
Der Compiler hat nämlich keine graphische Oberfläche.
Und zum C oder C++ lernen ist die Box sicherlich die falsche Plattform (hello-world.c sieht halt auf der Box auch nicht anders aus als überall anders).

Grüße

Andreas

[Lemmi]

In Ergänzung zum Andreas:

Als ich das Programm stdin2tcp für die Box geschrieben habe, habe ich es vollständig unter Linux auf dem PC entwickelt. Erst als alles (die erste Version) fertig war, habe ich den mips-Compiler angestossen und das Ergebnis auf der Box ausgeführt.

[Lemmi]

schon merkwürdig! der strip aus binutils 2.13 scheint die Binaries kleiner zu machen als der aus der 2.15er (beide ungepatchte Versionen). Wundert mich aber das das funktioniert. Hatte soviele Versions Probleme, dass ich immer die Versionen benutzt, mit denen auch kompiliert wurde. Siemens-Tools mit der 2.15er strip funktionierte nämlich gar nicht.
Naja im Grunde sollte ich froh sein, dass der Compiler überhaupt läuft ....
s
Heißt das nun, dass ich besser beim alten toolchain bleiben soll?

[andreas.koch]

Heißt das nun, dass ich besser beim alten toolchain bleiben soll?
Nein! Das neue wird nicht schlechter sein als das alte.
Das Problem ist: Den Compiler überhaupt ans laufen zu bekommen, was an der engen Verbundenheit des Compilers mit der glibc liegt. Ohne Patches (die aber eingentlich für die neuste Version der uclibc sind) läuft er gar nicht (produziert halt SegFaults).
Die meisten Probleme macht der locale-Support, der in der uclibc V. 0.9.19 nur ziemlich rudimentär enthaten ist. (Man muß halt ziemlich daran rumbasteln, ein paar Teile (in der stdc++) sind auch generic-parts des Compilers)
In der alten Version des Compilers war der einfach abgeschaltet. Was aber zu Problemen mit z.B. isspace usw. geführt hat.
Ich hoffe das funktioniert jetzt besser.

Grüße

Andreas

[Lemmi]

Ich wollte gerade mal stdin2tcp mit dem neuen Compiler übersetzen.
Fehler: /usr/local/mips-m740av-toolchain-2005-07/bin/../lib/gcc-lib/mips-linux-uclibc/3.3.6/../../../../mips-linux-uclibc/bin/as: error while loading shared libraries: libopcodes-2.16.1.so: cannot open shared object file: No such file or directory

Sie existiert aber: /usr/local/mips-m740av-toolchain-2005-07/i686-pc-linux-gnu/mips-linux-uclibc/lib/libopcodes-2.16.1.so

Wat nu?

[andreas.koch]

/usr/local/mips-m740av-toolchain-2005-07/i686-pc-linux-gnu/mips-linux-uclibc/lib/libopcodes-2.16.1.so

Argh! Habe wohl blöderweise die binutils shared compiliert.
Ist aber eine i686-native lib.
Man muß halt nun noch den ld-path (LD_LIBRARY_PATH geht) entsprechend setzten.
Ist mir nicht aufgefallen, da der Standard-Path der Lib für mein Installionsverzeichnis korrekt ist.

Grüße

Andreas

[Install]

@andreas.koch und Lemmi
Vielen Dank für die Antwort! Werde mich mal am Wochenende an „Hello World“ auf der Box versuchen.

Viele Grüße
Install

[grisu]

Hi Andreas,
kannst du mir mal einen Tip geben,
wie mal den Librarypath setzt?
(habe mit deiner ersten Compilerversion einiges uebersetzt,
mit dem jetzigen Compiler bin ich nicht weitergekommen)

Danke
grisu

[andreas.koch]

Hallo grisu,

man kann den Library Path auf mehrere Arten setzen eine ist die Environment-Variable LD_LIBRARY_PATH ein Kommando sehe dann so aus:
export LD_LIBRARY_PATH=/home/andreas/m740_src/m740av_toolchain/i686-pc-linux-gnu/mips-linux-uclibc/lib:$LD_LIBRARY_PATH

Der Teil-Pfad /home/andreas/m740_src/m740av_toolchain muß dann natürlich auf dein Installationsverzeichnis der Toolchain gesetzt werden.

Oder du editierst (falls du den Pfad dauerhaft setzen möchtest) die Datei /etc/ld.so.conf, und fügst den Pfad (z.B. /home/andreas/m740_src/m740av_toolchain/i686-pc-linux-gnu/mips-linux-uclibc/lib) in einer eingenen Zeile an die Datei an.
Dann muß du aber als root noch das Kommando ldconfig ausführen.

Grüße

Andreas

[grisu]

Hi Andreas,
werde ich mal probieren.

Danke
grisu

[Lemmi]

Argh! Habe wohl blöderweise die binutils shared compiliert.
Ist aber eine i686-native lib.
Man muß halt nun noch den ld-path (LD_LIBRARY_PATH geht) entsprechend setzten.
Ist mir nicht aufgefallen, da der Standard-Path der Lib für mein Installionsverzeichnis korrekt ist.

Grüße

AndreasUnd was ist der Standardpfad?
Mit der Umgebungsvariable LD_LIBRARY_PATH finktioniert es nämlich auch nicht.

Nachtrag: habe das Verzeichnis /home/andreas/... eingerichtet. Damit geht's.

[andreas.koch]

Und was ist der Standardpfad?
Habe die komplette toolchain in /home/andreas/m740_src/m740av_toolchain liegen.

Mit der Umgebungsvariable LD_LIBRARY_PATH finktioniert es nämlich auch nicht.
Das ist schon sehr merkwürdig, da ich das getestet hatte bevor ich es geschrieben hat (die toolchain hatte ich natürlich wo anders hin verschoben)

Grüße

Andreas

[Lemmi]

@andrea.koch:
Mein eigentliches Problem:
Ich wollte ein anderes nohup compilieren -- vieleicht ist es etwas kleiner.
Ich kann aber keine lib entdecken, die die Funktionen err() und errx() enthält. hab auch schon mips-nm bemüht.

Dirk

P.S.: Was hälst du von dem toolchain, das madsix vorgestellt hat?

[Lemmi]

Habe die komplette toolchain in /home/andreas/m740_src/m740av_toolchain liegen.

Das ist schon sehr merkwürdig, da ich das getestet hatte bevor ich es geschrieben hat (die toolchain hatte ich natürlich wo anders hin verschoben)
Wenn ich deinen pfad verwende, dann funktioniert es. Dabei ist der Inhalt von LD_LIBRARY_PATH unerheblich. Stimmt evtl. der Name nicht?

[andreas.koch]

Hab auch so ein paar Sachen testweise neukompiliert. tar ist dabei z.b. nur halb so groß. Hatte vor ein neus rootfilesystem zu bauen hat aber bis jetzt nicht ganz geklappt (siemens hat erstens sicher nicht alle GPL-Tool beigelegt z.b. sysvinit und net-tools , einige Libs sind außerdem merkwürdig kompiliert und das steht scheinbar auch nicht in dem Siemens-Packet).

Das Funktionen in der uclibc nicht enthalten sind passiert mir regelmäßig. Die neuste ulibc hat damit nicht mehr so extreme Probleme, versteh nicht warum siemens so eine alte Lib benutzt. Damit handelt man sich mehr Probleme ein als nötig.



Was hälst du von dem toolchain, das madsix vorgestellt hat?

Welche meinst du die egcs oder die andere? Hab beides nur kurz überfolgen.
Halt das im übrigen für nicht sehr klug den Kernel auszutauschen, bei den mtd-tools stand glaube ich irgendwo was von x Versuchen, damit man ein lauffähiges System erhält.


Grüße

Andreas

[Lemmi]

Das Funktionen in der uclibc nicht enthalten sind passiert mir regelmäßig. Die neuste ulibc hat damit nicht mehr so extreme Probleme, versteh nicht warum siemens so eine alte Lib benutzt. Damit handelt man sich mehr Probleme ein als nötig.
Ich hab's jetzt gelöst, indem ich die fehlenden Funktionen als Quelle (aus 1.49.5 util-linux-2.11h) eingebaut habe. Das binary ist jetzt nur noch 10kb anstatt 40kb groß.

Nächste Kanidaten sind bash, tar, pure-ftpd und e3fsck. Letzteres will ich wieder in die box bringen, um automatisch vor dem mount ein Plattencheck anzubieten. Daher benötige ich auch den Platz.




Welche meinst du die egcs oder die andere? Hab beides nur kurz überfolgen.
Halt das im übrigen für nicht sehr klug den Kernel auszutauschen, bei den mtd-tools stand glaube ich irgendwo was von x Versuchen, damit man ein lauffähiges System erhält. Ich meinte ersteres. Da ,dein' cross-compiler bisher hervoragend funktioniert, verlasse ich mich hier weiterhin ganz auf dich.

[andreas.koch]

Das binary ist jetzt nur noch 10kb anstatt 40kb groß.
Das hört sich gut an.


Nächste Kanidaten sind bash, tar, pure-ftpd und e3fsck. Letzteres will ich wieder in die box bringen, um automatisch vor dem mount ein Plattencheck anzubieten. Daher benötige ich auch den Platz.

bash bracht bei mir nicht viel ist dann ca. 914000 Bytes groß (wichtig dabie ist nls und regular expressions abzuschalten, auch wenns schade um die regex ist) tar habe ich hier, braucht ca 240000 Bytes statt ca 523000.
pure-ftpd habe ich nicht getestet. e2fsck hat bei mir shared ca. 221000 Bytes.
Wenn du Platz brauchst gibt es IMO noch ein paar Kandidaten zum löschen:
/lib/ld.so.2
/lib/ld-uClibc-0.9.5.so
(^alte uclibc Version die scheinbar von nichts gebraucht wird)
/lib/ld.so.1
/lib/libmemusage.so
/lib/libSegFault.so
(^ gehören zu einer glibc und machen auf der Box keinen Sinn)
/usr/lib/libiberty.so
(^ ist eine Lib des GCC/binutils und unterstützt eigentlich keine shared-build)

libintl.so.1.0.1 ist zwei mal vorhanden in /lib und /usr/lib eine sollte eigentlich reichen. Da die aber eigentlich für Internationalisierung (gettext) benutzt wird könnte man die wahrscheinlich auch löschen.



Ich meinte ersteres. Da ,dein' cross-compiler bisher hervoragend funktioniert, verlasse ich mich hier weiterhin ganz auf dich.
werd mir das egcs-toolchain mal bei Gelegenheit anschauen. Hab da auch noch ein paar andere Vermutung, wie der egcs benutzt worden sein könnte.
Denke man sollte dann aber erstmal mit ein paar Modulen versuchen, bevor man ein neues Kernel einbaut (was IMO höchst wahrscheinlich Probleme machen wird).

Grüße
Andreas

[MartinO]

Nächste Kanidaten sind bash, tar, pure-ftpd und e3fsck..

Wie schaut es denn mit der busybox aus? Ich nehme mal an, dass die der Box mit dieser hier (http://www.busybox.net/downloads/BusyBox.html) identisch ist (oder irre ich da?), womit sich wahrscheinlich noch eine Menge anderer Kommandos relativ platzsparend realisiseren ließen, wenn man mehr Optionen beim rekompilieren einschließt.

Gruß, Martin

[Lemmi]

Wie schaut es denn mit der busybox aus? Ich nehme mal an, dass die der Box mit dieser hier (http://www.busybox.net/downloads/BusyBox.html) identisch ist (oder irre ich da?), womit sich wahrscheinlich noch eine Menge anderer Kommandos relativ platzsparend realisiseren ließen, wenn man mehr Optionen beim rekompilieren einschließt.Ich denke auch, dass es sich um diese handelt. Die Quellen leigen auch der Siemens-GPL-Source bei.

Kanidaten wären u.a. tar, bunzip2, bzcat, (wo ist bzip2?), inetd, top, renice, dos2unix, traceroute, ping.

Nice to have (also was zum Spielen auf der Box): awk, egrep, wget.

Und dann gibt es da auch noch httpd und crond?

Man sollte sich bei einigen Programmen allerdings die Frage stellen, warum die Siemensianer die Vollversion und nicht die busybox-Version verwendet haben.

[pc-medusa]

Hallo,
Hab mir auch mal mutig wie ich bin den Cross-compiler auf meinem Linux installiert.
Wollte damit, Nachdem mir das unter (Suse) linux so gut gelungen ist mal ein kleines Programm kompilieren, welches ein USB-LCD Display ansteuert ( So 2 oder 4 Zeilen, damit man für Audio nicht immer den Fernseher einschalten muss)
Erwartungsgemäß ruft das Programm natürlich einige nicht vorhandene lib (?) auf. Erstmal scheitere ich an der usb.h welche nicht gefunden wird. Nu blicke ich bei den Verzeichnissen von dem Crosscompiler auch nicht so ganz durch, was wo hingehört. Im Verzeichniss include/linux steht z.B. eine usb.h. Kann/soll man die irgendwo anders hin kopieren oder braucht man da eine spezielle usb.h ( eigentlich sollten ja die C-Quellen gleich sein) oder muss man noch einen Link setzen oder eine Umgebunsvariable ?? Bei der usb.h wird es ja nicht bleiben, und dann müssen ja noch die entsprechenden Quellen (usb.c .. ) kompiliert weden und dann wird der Platz möglicherweise knapp ... Fragen über Fragen. evtl. hat ja jemand auch einen hilfreichen Link für mich ??

danke pc-medusa

[andreas.koch]

Im Verzeichniss include/linux steht z.B. eine usb.h. Kann/soll man die irgendwo anders hin kopieren oder braucht man da eine spezielle usb.h ( eigentlich sollten ja die C-Quellen gleich sein) oder muss man noch einen Link setzen oder eine Umgebunsvariable ?? Bei der usb.h wird es ja nicht bleiben, und dann müssen ja noch die entsprechenden Quellen (usb.c .. ) kompiliert weden und dann wird der Platz möglicherweise knapp ... Fragen über Fragen. evtl. hat ja jemand auch einen hilfreichen Link für mich ??

linux/usb.h gehört zum Kernel und muß auch in dem Verzeichnis bleiben.
usb.h gehört vermutlich zur libusb, die ist im Cross-Compiler nicht enthalten und müßte wenn möglich nachinstalliert werden.
Das Prog müßte dann statisch gegen die libusb gelinkt werden, da die auf der Box nicht vorhanden ist.
AFAIK setzt die lib auch noch ein gemountetes usbfs (nach /proc/bus/usb) voraus, das aber normalerweise nicht gemountet wird.

Grüße

Andreas

[pc-medusa]

@andreas.koch
Danke für die Ausführungen. Das bringt mich doch schon etwas weiter.

pc-medusa

[colomy]

Könnte man die Toolbox auch für das M740AV Linux compilieren?

Es wäre genial, dann könnte man die Toolbox auf die USB Platte kopieren und direkt dort kompilieren und testen.

@Andreas.Koch
Könntest du so eine Toolbox erzeugen?

[Lemmi]

Könnte man die Toolbox auch für das M740AV Linux compilieren?Welche toolbox?
(Hab' ich was verpaßt?)


Es wäre genial, dann könnte man die Toolbox auf die USB Platte kopieren und direkt dort kompilieren und testen.Testen: Ja
Dort compilieren: Nein, da der obige Cross-Compiler auf einem i386/linux läuft.

[colomy]

Sorry ich habe den Cross Compiler gemeint (toolchain).

Wenn man mit dem Compiler executables erzeugen kann, die auf der Box laufen, müsste man doch gcc,g++ und die libs damit auch cross compilieren können, oder bin ich irgendwelchen naiven Gedankenwirrwars gefolgt :o ?

[NullPtr]

Sorry ich habe den Cross Compiler gemeint (toolchain).

Wenn man mit dem Compiler executables erzeugen kann, die auf der Box laufen, müsste man doch gcc,g++ und die libs damit auch cross compilieren können, oder bin ich irgendwelchen naiven Gedankenwirrwars gefolgt :o ?
Rein theoretisch ja.
Aber wieviele Tage braucht das arme Prozessörchen der Box wohl, um eine 'hello world' zu kompilieren? ;)

[colomy]

Rein theoretisch ja.
Aber wieviele Tage braucht das arme Prozessörchen der Box wohl, um eine 'hello world' zu kompilieren? ;)

Unterschätzt mal nicht die Box. Kommandozeilentools unter Linux brauchen keinen schnellen Prozessor.
Auf meinem 600 MHZ Laptop kompiliere ich meine Anwendung in ca 3 Sekunden. Ich denke das wird ganz gut laufen.

Schön wäre auch noch eine Alternative zu vi, z.B. nedit auf der Box. Dann wäre meine Wunsch-IDE komplett :)

[Lemmi]

Unterschätzt mal nicht die Box. Kommandozeilentools unter Linux brauchen keinen schnellen Prozessor.
Auf meinem 600 MHZ Laptop kompiliere ich meine Anwendung in ca 3 Sekunden. Ich denke das wird ganz gut laufen.Da gibt es von LinuxDoc was: http://www.2eier.de/m740av/old/ Datei image.tar.bz2
Es handelt sich dabei um ein Entwicklungssystem für die Box. Ein Anleitung gibt es auch irgendwo im Linux Teil dieses Forums.



Schön wäre auch noch eine Alternative zu vi, z.B. nedit auf der Box. Dann wäre meine Wunsch-IDE komplett :)nano ist 'drauf.

[kille]

Hi,


Rein theoretisch ja.
Aber wieviele Tage braucht das arme Prozessörchen der Box wohl, um eine 'hello world' zu kompilieren? ;)
Ich nutze dieses Image von LinuxDoc (bzw. habe ich mir mittlerweile ein aktuelleres gebastelt). Ist zwar nichts für ungedultige Naturen, aber so ein FTP-Server compiliert damit in weniger als einer halben Stunde, php4 braucht inkl. configure auch nicht mehr wie 1,5 Stunden. Fernsehen nebenbei ist möglich, dauert dann natürlich "etwas" länger das Ganze.

Also noch im tolerierbaren Bereich - wenn man z.B. mit meiner Geduld gesegnet/gestraft ist.

Kille

[LinuxDoc]

@kille
kannst du das zur Verfügung stellen ?
Oder wenigstens mir, damit ich es auf den Webserver legen kann ?!?
Ich hoffe du hast nano schon drinnen :-)

Um die Sache zu beschleunigen kann man auch distcc (http://wiki.linuxquestions.org/wiki/Distcc) benutzen, das ist in meinem Image auch schon dabei.

[kille]

Hi,

klar kann ich das zur Verfügung stellen. Ist allerdings ein ganz normales rootfs von der kernel.org Seite, leicht vergrößert und mit nano angereichert. Aber vielleicht hilfst es ja dem einen oder anderen weiter:

http://kille.cx/downloads/m740av/root_fs_mips.ext2.bz2

Kurzanleitung dazu:

Die Datei in ein fast beliebiges Verzeichnis entpacken. Das Verzeichnis muss von der Box erreichbar sein, und man sollte wissen wie ;)

Danach die folgenden Zeilen (jeweils nur das nach dem # ) eingeben:

sh-2.05# mount -o loop /pc1/temp/root_fs_mips.ext2 /mnt
sh-2.05# mount --bind /var/media/PC2/ftpd/ /mnt/home/k
sh-2.05# cd /mnt
sh-2.05# chroot /mnt
sh-3.00# mount /proc

In der ersten Zeile müßt ihr das Verzeichnis ändern, in dem ihr das rootfs entpackt habt, bei mir ist das /pc1/temp/

In der zweiten Zeile wird ein Arbeitsverzeichnis (dort kommen die Sourcen rein und dort findet ihr die fertig compilierten Sachen) eingebunden. Dieses Verzeichnis sollte sowohl von der Box aus wie auch von eurem PC aus erreichbar sein, das erleichtert die Arbeit ungemein. Bei mir wird das Arbeitsverzeichnis nach /mnt/home/k eingebunden, ihr könnt aber auch jedes beliebige Verzeichnis nehmen, welches ihr vorher aber erstellen müßt und welches sich zudem unter /mnt befinden muss!

Nach der letzten Zeile seit ihr grob besprochen in einer anderen Linuxumgebung. Unterschiede: ihr seht das Verzeichnis der Box nur ab /mnt (also kein direkter Zugriff auf die USB Platte o.ä.!), und ihr habt einen Compiler zur Verfügung.

Das Arbeitsverzeichnis /mnt/home/k erreicht ihr jetzt über
cd /home/k, da ihr ja wie beschrieben in euch wie beschrieben in einer neuen Umgebung befindet, die erst bei /mnt losgeht!

Viel Spass damit.
Kille

[colomy]

Viel Spass damit.
Kille

Den hatte ich gestern :D

Funktioniert sehr gut. Konnte mein txt2osd Projekt in einer Minute übersetzten. Das ist OK. Da es in 6 Klassen unterteilt ist geht das kompilieren sehr schnell, wenn ich nur an einer editiert habe.

Eine echte Bereicherung ! Danke.

Es gibt eine Kleinigkeit.
Die Box verwendet libstdc++.so.5, in dem compiler auf deinem rootfs ist aber libstdc++.so.6 verwendet. D.h. ich muss derzeit immer statisch linken. Könnte man da einen "älteres" rootfs verwenden das mit Version 5 arbeitet?

Colomy

[kille]

Hi,


Könnte man da einen "älteres" rootfs verwenden das mit Version 5 arbeitet?
Wahrscheinlich. Da ich bis jetzt aber immer statisch compiliert habe (ich bin nicht so gut was Linux und libs und compilieren usw. angeht, da ist statisch immer einfacher ;), habe ich das aber noch nicht ausprobiert. Werde ich aber mal machen sobald ich die Zeit dazu finde.

Kille

[golem]

Danach die folgenden Zeilen (jeweils nur das nach dem # ) eingeben:

sh-2.05# mount -o loop /pc1/temp/root_fs_mips.ext2 /mnt
sh-2.05# mount --bind /var/media/PC2/ftpd/ /mnt/home/k
sh-2.05# cd /mnt
sh-2.05# chroot /mnt
sh-3.00# mount /proc


Hi,
bei mir klappt es nicht:


sh-2.05# mount -o loop /pc1/root/root_fs_mips.ext2 /mnt
can't create lock file /etc/mtab~4478: Read-only file system (use -n flag to ove
rride)
sh-2.05#


gruß golem

[Lemmi]

@golem:
Nimm in den mount-Befehl die Option -n hinzu.

[golem]

@golem:
Nimm in den mount-Befehl die Option -n hinzu.
ja wenns denn so einfach wäre ;)


sh-2.05# mount -o -n loop /pc1/root/root_fs_mips.ext2 /mnt
can't create lock file /etc/mtab~4662: Read-only file system (use -n flag to ove
rride)
sh-2.05#

[MartinO]

ja wenns denn so einfach wäre ;)


sh-2.05# mount -o -n loop /pc1/root/root_fs_mips.ext2 /mnt
can't create lock file /etc/mtab~4662: Read-only file system (use -n flag to ove
rride)
sh-2.05#

"-o loop" gehören zusammen (Option "loop"). "mount -n -o loop /pc...." sollte also besser funktionieren...

Gruß, Martin

[golem]

Vielen Dank klappt :)

[MartinO]

from http://www.m740.de/forum/showthread.php?t=2782:


cross toolchain can be hosted under Microsoft Windows or Linux
@ Lurch,

erst mal vielen, vielen herzlichen Dank für dieses Makefile! Ich habe mich monatelang davor gedrückt, mir die nötigen Klamotten für eine Cross-Toolchain zusammenzusuchen (was zu einer gewissen Skript-Lastigkeit meiner Lösungen führte... ;) ), und jetzt ging es mit wenigen Anpassungen (für SuSe 9.1) in deutlich unter einer Stunde Arbeitszeit inklusiver aller Bibliotheken. Deine clock-Demo habe ich auch schon selbst übersetzt. Toll!

Allerdings bin ich gestern erst durch Zufall darauf gekommen, dass das so schmerzfrei auch unter Linux funktioniert. Wegen des Titels (mit CYGWIN) hatte ich diesen Tread bislang weitestgehen ignoriert! Damit das anderen nicht ähnlich geht, habe ich das hier noch mal in diesem Thread untergebracht.

Gruß, Martin

[colomy]

Hi,

klar kann ich das zur Verfügung stellen. Ist allerdings ein ganz normales rootfs von der kernel.org Seite, leicht vergrößert und mit nano angereichert. Aber vielleicht hilfst es ja dem einen oder anderen weiter:

http://kille.cx/downloads/m740av/root_fs_mips.ext2.bz2


Hi kille,

der Kernel der Box is mit gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) kompiliert.
Das Kernelmodul das ich versuche läuft bisher nicht, und ich denke es liegt an der Compilerversion.
Jetzt hätte ich folgende Idee. Könnte man in dein rootfs auch diesem Compiler mit dazupacken (http://gcc.fyxm.net/releases/egcs-1.1.2).
Ich denke das optimale wäre alle libs direkt von der Box zu nehmen und die Kernel Sourcen von gigaset_m740av_gplsw/linux-2.4-xfs/linux.

Könntest du sowas zusammen stellen, oder kurz erklären wie du das andere rootfs gemacht hast.

Merci,
Colomy

[andreas.koch]

der Kernel der Box is mit gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) kompiliert.
Das Kernelmodul das ich versuche läuft bisher nicht, und ich denke es liegt an der Compilerversion.

Mit hoher Wahrscheinlichkeit nicht nur an der Compiler Version.
Den egcs ans Laufen zu bringen ist ein Wissenschaft für sich, es existiert dazu irgendwo im Linux-Projekt ein Beschreibung, die ich aber noch nicht getestet habe.
Habe mal ein Test-Modul mit dem Compiler von mir geschrieben (s. Link weiter oben), das auch lief. Allerdings ist das Kernel auf der Box gelinde gesagt stark beschränkt (was mich angeht, es wundert mich das das überhaupt läuft).
Was für ein Modul willst du den bauen?



Jetzt hätte ich folgende Idee. Könnte man in dein rootfs auch diesem Compiler mit dazupacken (http://gcc.fyxm.net/releases/egcs-1.1.2).
Ich denke das optimale wäre alle libs direkt von der Box zu nehmen und die Kernel Sourcen von gigaset_m740av_gplsw/linux-2.4-xfs/linux.

Wenn das so einfach wäre! AFAIK ist das rootfs das von ulibc.org oder mit dem buildroot Makefile-System generiertes System. Diese läuft nur weder mit der auf der Box verwendeten uclibc Version noch mit dem Compiler zusammen. Da muß man schon von Hand einiges machen, damit man einen läuffähigen Compiler erhält.
Den egcs zum Laufen zu bewegen erfordert wohl noch etwas mehr an handarbeit.

Grüße

Andreas

[kille]

Hi,

Andreas hat ja schon einges dazu geschrieben. Ich kann nur hinzufügen: sehr wahrscheinlich kann ich da keinen weiteres Compiler hinzufügen, da ich in Sachen Linux, Compiler, C usw. nicht sonderlich bewandert bin, mit Kernelmodulen hab' ich noch nichts zu tun gehabt, nichteinmal einen eigenen Kernel hab' ich jemals in meinem Leben gebacken... Und was ist überhabt egcs?

Aber: ausser dem Paket von Andreas kannst du es ja auch mal mit dem Cygwin Cross-Compiler von Lurch probieren, vielleicht tuts der ja:
http://www.m740.de/forum/showthread.php?goto=newpost&t=2782

Kille

P.S. Das rootfs hab' ich zwar von Kernel.org, ist aber AFAIK das gleiche wie von uclibc.org.

[colomy]

Was für ein Modul willst du den bauen?


Das Ziel ist dem proc file system zusätzliche Infos zu verpassen. Das Einklinken von neuen Infos klappt ohne Probleme.

Die Zusatzinfo ist neben dem Filedescriptor auch die Fileposition eines von einem Prozess geöffneten Files anzuzeigen.
Ich brauche dass um zu wissen wo die Box beim Playback einer Sendung ist.

Die Funktion im Kernel sieht aus wie in http://www.m740.de/forum/showthread.php?t=3157
beschrieben.

Ich hab auch email Kontakt mit einem Kernelprogrammierer, der was ähnliches gemacht hat, der meinte, dass der Zugriff so klappen müsste und es sehr wahrscheinlich an der Compilerversion liegt.

Gruss, Colomy

[colomy]

Eine andere Möglichkeit wäre den Kernel und die Kernelmodule mit gcc 3.2.3 zu überstzen.

@ Lemmi, hast du Durchgriff in das System um auch Kernel und Kernelmodule zu tauschen?

Oder könnte mann die Box dazu bewegen per Bootmanager zum Testen von der externen USB disk zu booten. Wohl eher nicht wegen evtl. fehlendem USB support im BIOS.

[andreas.koch]

Das Kernel neu compilieren geht deswegen nicht, da nicht alle Treiber im Source verfügbar sind.
Dein Problem hat aber vermutlich aber nichts mit dem Compiler zu tun.
Was auf einem Standard-Linux-Kernel geht muß nicht auf der Box gehen.
Die von dir verwendete Funktion get_files_struct gibt es im Kernel auf der Box gar nicht. (Maßgeblich sind hier die Siemens-GPL Sourcen, und die sind Teilweise weit von einem normalen Kernel entfernt, bei schreiben von Kernel-Modulen für die Box ist es unerläßlich da rein zu schauen).
Die Ersetzung get_files_struct(task) durch task->files sollte aber gehen.
(Danach aber in keinem Fall put_files_struct aufrufen, die allerdings vom Kernel der Box auch nicht exportiert wird).

Grüße

Andreas

[colomy]

Die von dir verwendete Funktion get_files_struct gibt es im Kernel auf der Box gar nicht. (Maßgeblich sind hier die Siemens-GPL Sourcen, und die sind Teilweise weit von einem normalen Kernel entfernt, bei schreiben von Kernel-Modulen für die Box ist es unerläßlich da rein zu schauen).
Die Ersetzung get_files_struct(task) durch task->files sollte aber gehen.

task->files hatte ich als erstes versucht, aber nachdem das immer ein NULL pointer war habe ich mal andere Sachen probiert.
Aber du hast recht ich sollte darauf zurückgehen.

Schöne Grüsse, Colomy