Freetz MOD: Probleme beim Kompilieren von make 3.81

[Kontr-Olli]

hallo comunity....

habe soeben versucht mit freetz das Paket "GNU make 3.81" zu bauen, da ich versuchen wollte direkt auf der FB 7270 Programme zu kompilieren, ohne den meist sehr mühsamen weg über den toolchain crosscompiler zu gehen....

ich hatte in einer "älteren" version von freetz-dev, ich glaub es war die dev-26xx mit FW 54.04.59 oder so schon bereits es erfolgreich geschafft, make 3.81 ohne fehler zu kompilieren.....seid ein paar versionen vom svn dev rep. samt neuer .67er FW ist es mir jedoch nicht mehr möglich freetz mit aktiviertem make 3.81 fehlerfrei zu kompilieren...es kommt stets folgende Fehlermeldung...

-DLIBDIR=\"/usr/lib\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I. -I. -I.  -I/glob    -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT getopt1.o -MD -MP -MF ".deps/getopt1.Tpo" -c -o getopt1.o getopt1.c; \
	then mv -f ".deps/getopt1.Tpo" ".deps/getopt1.Po"; else rm -f ".deps/getopt1.Tpo"; exit 1; fi
dir.c: In function 'dir_setup_glob':
dir.c:1201: error: 'glob_t' has no member named 'gl_opendir'
dir.c:1202: error: 'glob_t' has no member named 'gl_readdir'
dir.c:1203: error: 'glob_t' has no member named 'gl_closedir'
dir.c:1204: error: 'glob_t' has no member named 'gl_stat'
make[3]: *** [dir.o] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[3]: Leaving directory `/home/kontr-olli/Desktop/freetz-trunk2/source/make-3.81'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/kontr-olli/Desktop/freetz-trunk2/source/make-3.81'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/home/kontr-olli/Desktop/freetz-trunk2/source/make-3.81'
make: *** [source/make-3.81/make] Fehler 2

vielleicht kann mir jemand von euch ja weiterhelfen.....vielen dank!!

Kontr-Olli

 

[olistudent]

Sieht so aus als wäre das Ergebnis vom configure i.V.m uClibc-0.9.29 falsch. Ich setze es auf die Todo-Liste...

MfG Oliver

 

[Kontr-Olli]

besten dank!!

Kontr-Olli

 

[olistudent]

Das Problem ist leider doch größer als angenommen. Mit uClibc-0.9.29 wurde ein neuer Parameter "UCLIBC_HAS_GNU_GLOB" eingeführt. Dieser ist deaktiviert. Daher wird das in uClibc-0.9.29 nicht unterstützt. Ich hatte mit 0.9.28 probiert und da funktioniert es.

Die nötige uClibc-Version hängt von der AVM Firmware ab. Wenn du die Toolchain selbst baust, dann kannst du mit "make uclibc-menuconfig" die Option unter "Big and Tall" selbst anschalten. Die Option braucht 4kb. Die Frage aber ist, ob es Sinn macht die anzuschalten, weil sich noch kein anderes Paket beschwert hat.

MfG Oliver

 

[Kontr-Olli]

ja, ok....werd es dann gleich mal testen....4KB dürfte mein image noch verkraften ;-)....danke für die hilfe!!....

apropo....da ich anscheinend hier grade mit einem profi zutun habe, am rande gleich nochmal ne frage....und zwar versuche ich grade truecrypt 6.1 zum laufen zu bekommen.....und soweit hab ich es auch hinbekommen.....leider aber nur über umwege....

ich beschreib mal kurz mein vorgehen und hoff, dass du mir ev. weiterhelfen kannst....
hab zunächst die kompilierte version von truecrypt 6.1 von hier runtergeladen http://www.ip-phone-forum.de/showthread.php?t=111024&page=2&highlight=truecrypt....danach einen truecrypt container erstellt....bishier lief alles wie geplant.....als ich aber versucht habe den truecrypt-container zu mounten, beschwert sich tc über das fehlende modul fuse....also gesagt getan....modprobe fuse...und modul war danach auch da....komischerweise war zwar das modul da, aber es war trotz allem kein /dev/fuse zu finden....deswegen konnte ich nichts mounten.....aber mir war bewusst, dass das Paket WebDAV aus freetz ja auch auf fuse aufbaut....also hab ich einfach mal WebDAV gestartet....und auf einmal war das /dev/fuse da....und nun lies sich auch der truecryptcontainer ohne probleme mounten.....

nun meine frage....muss ich bei modprobe fuse besondere parameter übergeben damit ich das /dev/fuse anlegen kann....oder kannst du mir ev. sagen was bei WebDAV genau passiert, wenn es das fuse-dev anlegt....vielen dank im vorraus...

Kontr-Olli

@olistudent
mhhh....ja ok, sollte eigentlich so sein....aber komisch ist, dass modprobe fuse zunächst nicht ausreichte.....erst nachdem ich WebDAV gestartet habe, konnte ich aufeinmal auch truecryptcontainer über fuse mounten.....ich werds mal beobachten.....und bei gelegenheit berichten, wenn ichs rausbekommen habe...

Kontr-Olli

 

[olistudent]

/dev/fuse sollte unter Freetz immer da sein. Und sobald das Modul geladen ist auch funktionieren.

MfG Oliver

 

[matze1985]

ich hab das gleich, /dev/fuse existiert auch noch einem modprobe nicht, aber nach dem start von webdv ist alles da.

Kann aber nix im scipt finden.

 

[olistudent]

Okay. Freetz legt /dev/misc/fuse an. Da muss ich mal nachschauen, ob das geändert werden sollte.

MfG Oliver

edit: Ich werde /dev/fuse hinzufügen, so dass beide Devices erzeugt werden.

 

[matze1985]

Danke, dass ist super.

 

[Kontr-Olli]

hi...

@olistudent

jo, danke....wäre auf jedenfall hilfreich sowohl für truecrypt als auch für andere programme die /dev/fuse und modul fuse benötigen.....

noch mal ne andere frage.....wegen make 3.81....hab gestern versucht, wie du beschrieben hast unter freetz-trunk ein "make uclibc-menuconfig" zu machen.....hab dann unter "big and tall" das entprechende gnu_glob aktiviert......und erneut einfach nur make ausgeführt um das freetz image zu bauen....leider selber fehler wie zuvor...bleibt bei make "make 3.81" hängen.....danach hab ich einfach mal die entsprechenden dateien von uclibc aus dem ordner build gelöscht, damit er uclibc bei make mit neu baut....auch wieder kein erfolg....kannst du mir sagen, wie ich uclibc nach "make menuconfig uclibc" und entsprechender wahl von gnu_glob neu bauen kann....und auch dass er dieses uclibc dann für das make des freetz image verwendet....danke!!

Kontr-Olli

 

[matze1985]

mal mit

make uclibc-dirclean

versucht?

 

[olistudent]

Wahrscheinlich hast du im menuconfig nicht "Build Toolchain" sondern "Download Toolchain" unter Advanced Options -> Compiler Options ausgewählt.

MfG Oliver

 

[Kontr-Olli]

@olistudent

jo, danke....daran lags....hab mir mal den toolchain crosscompailer jetzt selber gebaut....und auch mit dem wie du beschrieben hast für die uclibc die gnu_gnop extensions....und jetzt kann ich auch make 3.81 kompilieren....werds mal nächste woche testen....

anbei, mir ist aufgefallen, dass sich seit rev. 2925 das transmission-paket nicht mehr ordnungsgemäß kompilieren lässt....es gibt allerdings seit gestern eine neue stable transmissionversion....1.42....hab einfach mal den source code nach .../source/transmission-1.40 enpackt und touch .unpacked gemacht....also die neue version lässt sich komischerweise ohne fehlermeldung compilen....allerdings hatte ich noch keine möglichkeit die bins zu testen....ev. könntest du das neue 1.42er paket ins neue freetz mit aufnehmen....


Kontr-Olli

 

[olistudent]

Hallo.
Hab grad gemerkt, dass das mit dem glob_t aus dem ersten Post doch ein Fehler ist. Es geht auch ohne die uClibc Option...
http://www.freetz.org/changeset/3161

MfG Oliver

 

[linuxkasten]

Hab auch noch ´ne Frage:
Bei dem make-Paket ist dann der gcc und die ganze Toolchain schon gleich mit dabei, oder?

 

[hermann72pb]

Naja, das sind drei unterschiedliche Sachen nach meinem Verständnis: gnu-make, gnu-c und toolchain. Und die braucht man alle, um was Vernünftiges zu machen. Ich gebe zu, ich hatte Oliver Ende letzten Jahres dazu eingestiftet einen "onboard compiler" zu kompilieren. Daraus entstanden wahrscheinlich diese Pakete. Mit Olivers Hilfe (Danke nochmal!) ist mir damals gelungen die drei Komponenten zu kompilieren. toolchain muss man schon selbst bauen, es ist richtig und sonst ging es auch nicht so einfach. Als Ergebnis hatte ich irgendwann mal ein Haufen von Dateien, die über 200MB wiegen. Als ich das gesehen hatte, ist mir mein Wunsch schnell vergangen damit ernsthaft was auf der Box zu kompilieren. Aber größtenteils lag es daran, dass ich nicht dazu gekommen bin.
Die Hauptmotivation dazu war, dass man so ein kleines Programmchen "Hallo Welt!" mal direkt auf der Box mit "make" oder mit "gcc" übersetzen könnte und direkt starten könnte, so wie es halt in der normalen Linuxwelt üblich ist. Vermutlich wird es sogar mit einem kleinen Programmchen gehen. Firmware oder einzelne Pakete damit zu kompilieren, das kann man, denke ich, wegen der beschränkten Box-Leistung vergessen.

Du kannst es aber gerne ausprobieren und uns darüber berichten. Wir helfen dir gerne bei deinen Problemen weiter.

MfG

 

[Kontr-Olli]

kompilieren auf der FritzBox

Hi,

ich schließe mich meinem Vorredner an....auf der FB etwas zu kompilieren (jedenfalls größere Pakete abseits von "Hello world") ist reine nervensache....und es kommt auch mehr als häufiger vor, dass sich die Box während "make" einfach mal verabschiedet und neu startet.....
als ich meine ersten kompilier-versuche gestartet habe, habe ich anfangs den im freetz-paket enthaltenen cross-compiler (toolchain) verwendet....auf die dauer war das sehr lästig und manche programme/pakete ließen sich auch nicht mit dieser cross-umgebung kopilieren (siehe mldonkey für FB; dazu wird ein eigener compiler benötig (ocaml), welcher sich nicht cross-compilen ließ)...des weiteren empfand ich die unzähligen zusatz-angaben für configure bzw. make beim cross-compilen sehr lästig.....auch das einbinden zusätzlicher libs etc. (für statische pakete) war meist sehr unübersichtlich bis nahezu unmöglich....

im zweiten versuch habe ich mir ein debian lenny für mips per debootstrap (im freetz-paket enthalten) auf meinen USB-datenträger für die FB gebaut.....man konnte komfortabel mit dem chroot-befehl ins debian debootstrab wechseln und dort analog zu einem ganz normalen linux per apt-get die benötigten pakete installieren und dann per configure und make ganz einfach eigene pakete kompilieren.....das funktioniert, wenn man genügend geduld und zeit mitbringt auch sehr gut.....einziges manko.....fürs kompilieren an sich benötigt man schon einiges an ressourcen....sehr cpu-lastig.....weshalb sich aus diesem grund bei mir die Box des öfteren einfach verabschiedet hat.....z.B. hab ich fürs kompilieren von mldonkey etwa 4-5 stunden mit 3-4 reboots gebraucht.....danach lief es aber als statisches paket sehr gut auch auf einer debian-losen umgebung......

mein empfehlung ist jedoch eine eigene kompilier-umgebung zu bauen.....ich verwende zur zeit das tool qemu, welches eine art vm-maschine zur verfügung stellt (emulator)......vorteil von qemu zu anderen vm's ist die tatsache, dass sich neben der hardware auch der cpu emulieren lässt.....bei mir auf dem laptop läuft auf einer externen Festplatte nun ein debian für mipsel.....qemu emuliert mir dafür basierend auf meinem laptop-cpu eine mipsel-cpu.....in dieser umgebung (debian lenny) lassen sich alle pakete ganz streßfrei wie gewohnt kompilieren und auch statisch linken.....die von mir dort gebauten pakete waren auch bisher uneingeschränkt auf meiner FB lauffähig....wer also schnell, einfach und unkompliziert paket für die FritzBox bauen möchte, dem empfehle ich den qemu mipsel emulator samt debian lenny....einfacher gehts nicht.....für weitere infos könnt ihr hier nachlesen:
http://www.aurel32.net/info/debian_mips_qemu.php

viel spaß beim kompilieren.....

gruß
Kontr-Olli

 

[hermann72pb]

Danke für die Tipps. Ich glaube, hier im Forum gab es bereits einige Versuche mit qemu. Wie verhält sich denn die Compilation unter quemu von der Geschwindigkeit her, wenn man es mit dem Crosscompiler vergleicht? Die Vorteile der "direkten" Kompilierung sind mir schon klar, gibt es dabei auch Nachteile außer Geschwindigkeit und Nichtverfügbarkeit einiger Geräte? Lässt sich die qemu-Umgebung so erweitern, dass man die Box möglichst "device-treu" nachbildet? Dass man z.B. character-Devices und squashfs emuliert/anbindet? Es geht mir mehr in die Richtung, dass man die Programme auch testen kann, ohne sie hin und her zu schieben.
Übrigens, ich habe so eine wilde Idee: Kann man nicht qemu und eine echte Box per NFS irgendwie "verheiraten". Man könnte dann von der Box aus z.B. "make" starten, es würde aber in Wirklichkeit unter "qemu" ausgeführt. Die kompilierte Datei würde dann auf der Box landen und könnte wiederum in der echten Boxumgebung ausgeführt werden. In diesem Fall könnte man sogar make-Prozess der Box überlassen und nur die eigentliche Compilierung auf "qemu" verlagern.

MfG

 

[Silent-Tears]

Die Idee ist ein wenig seltsam, denn wenn ich mal den NFS-Prozess betrachte, dann liegen nur die Daten woanders, die Ausführung (Prozessor, Speicher & IO) sind jeweils immer noch von der Box abhängig.
Allerdings gab es hier mal irgendwann etwas, was die Box (nicht komplett, aber zumindest teilweise) per quemu nachgebildet hat, bzw. das versucht hat. Wäre natürlich eine wiklich interessante Testumgebung, und würde dutzendfaches Flashen ersparen.

 

[RalfFriedl]

@hermann72pb
Wenn man eine Box mit qemu emuliert, gibt es keinen Grund für diese Konstruktion (die übrigens so nicht funktionieren kann, NFS ist nur ein Dateisystem).
Auch ist es zum Glück nicht notwendig, in qemu die gesamte Hardware zu emulieren, was ohne genaue Informationen von AVM auch sehr schwierig wäre.
Wichtig wäre allerdings die Emulation eines Netzwerk-Anschlusses, die meines Wissens im Moment auch nicht funktioniert. Damit könnte man in qemu Programme compilieren, ohne das Risiko eines Reboots. Diese könnten über NFS irgendwo abgelegt werden, wo die Box auch über NFS drauf kommt. Damit wäre direktes Kompilieren und Testen möglich.