EIn eigenes Programm kompilieren

[febo]

Hallo,

entsprechend den Sufu Ergebnisse habe ich mir nun viele Beträge zum Thema "kompilieren" durchgelesen doch leider bleiben noch Fragen offen, bevor ich ein Programm kompilieren und auf meiner Box zum laufen bekomme werde.

Zuerst besorgte ich mir das StinkyLinux Image und den VM Ware Player sowie das aktuelle freetz-1.0 trunk. Dieses läuft nun. Ein erstes Image für die FritzBox (7170 mit Firmware-Version 29.04.59-freetz-1.0-stable) habe ich erstellt und auf die Box geflasht.

Soweit war alles noch ganz einfach.

Nun möchte ich ein Programm namens "nethostfs" (für den Zugriff einer PSP [PlayStation Portable] auf freigegebe Verzeichnisse eines Rechners) kompilieren und ebenfalls auf der Box starten.

Einen Sourcecode habe ich mir heruntergeladen und auf das StinkyLinux System abgelegt.

In der Shell gehe ich nun in das Verzeichnis meines Programm bzw. Sourcecodes und setzte den Pfad zum toolchain von freetz.

Hier im Wiki lese ich nun von Optionen für configure. Und da fangen meine Probleme an.

Folgende Dateien sind bei meinem Sourcecode dabei:

main.c
Makefile
nethostfs.h
pspiofilemgr.h

Keine configure.

Was muss ich tun, um einen Sourcecode wie oben angegeben zu kompilieren. Wenn ihr noch Angaben benötigt liefere ich die natürlich gerne nach. Danke im Voraus für die Antworten.

Gruß

febo

 

[chked]

Probiers mal einfach mit

make

.
Wenn keine Compiler/Linker-Fehlermeldungen kommen, ist er erste Schritt schon mal getan.

 

[febo]

Hi chked,

vielen Dank erstmak für die schnelle Antwort die ich auch sofort umgesetzt habe. -wie -du bereits angedeutet hast, bekomme ich einige Fehlermeldungen:

cc -Wall -I. -c -o main.o main.c
main.c: In function 'main':
main.c:1000: warning: pointer target in passing argument 3 of 'accept' differ in signedess
cc -Wall -I.  -L -lpthread -L. lpthread -o nethostfe main.o

Leider bin ich nicht so der c oder c++ kenner und auch das kompilieren ist mir eigentlich in der Form neu. Soll heißen, ich kann damit nichts anfangen

Hast Du vielleicht eine Idee?

Hm...? Ich dachte mir, vielleicht müsste der path zum toolchain noch eingestellt werden und habe folgendes eingegeben:

PATH=/home/slightly/freetz/toolchain/target/bin:$PATH

Als ich nun wieder make eingab bekam ich folgende Meldung:

bash: Für das Ziel >all< ist nichts zu tun.

Na TOLL, was soll das denn nun heißen?

Gruß

febo

 

[bodega]

Fehlermeldungen werden generell mit "Error" gekennzeichnet. Das, was du geposted hast ist ein "Warning" und kann vernachlässigt werden.

Na TOLL, was soll das denn nun heißen?

Eben das was da steht. Nix. Alles fertig. Schaust du dir eigentlich den Build an, bevor du postest?

 

[febo]

Hi,

entschuldige meine Unwissenheit.

Gehe ich recht der Annahme, dass die von mir gepostete Ausgabe der Shell die von Dir angesprochene Build ist? Es tut mir leid, wenn ich dich mit meiner Unwissenheit langweile, nur Du kannst doch garnicht wissen wie lange ich mich mit dieser Shell Ausgabe beschäftigt habe, bevor ich den Post tätigte.

Nun gut...

Ich habe nach weiteren Recherchen die Makefile soweit angepasst, dass make ohne Fehlermeldungen beendet wird. Das fertige Programm läuft auch bereits auf der FritzBox.

Nun beschäftige ich mich mit der Port- und Verzeichnisfreigabe.

Danke nochmal.

Gruß

febo

 

[bodega]

Sorry. Wollte das nicht so hart ausdrücken. Ist eventuell falsch rübergekommen. Also mit Build meine ich, ob das gewünschte Ergebnis am Ende rausgekommen ist. Sprich: die Binaries. Wenn dem so ist, dann ist alles gut. Da das Programm bereits auf der FB läuft, kann man davon ausgehen.

Manchmal ist ein wenig Anpassungsarbeit angesagt, um Programme für die FB zu kompilieren. Häufig trifft das nur auf Pfade zu, für die Schreibrechte benötigt werden. Wenn dazu noch Libraries hinzukommen, wird es eine Spur schwieriger.

Was mir am Anfang etwas schwer gefallen ist, war die Tatsache, dass es (plötzlich) zwei Compiler unter Linux gibt. Einmal gcc für x86/x64 und einmal mipsel-linux-gcc aus dsmod/freetz. Libraries und Header vom x86/x64 werden im root abgelegt (/lib, /include, /usr/lib ...), wobei die Freetz-Toolchain ihre Libraries u. Header unter freetz/toolchain/target ablegt.

Ich habe mir deshalb angewöhnt, alle Pfade beim ./configure anzugeben, damit die Installation auf jedenfall in den richtigen Verzeichnissen statt findet. Dies ist nicht immer nötig, schaden kann es aber nicht:

./configure --bindir=/home/maz/freetz-trunk/toolchain/target/bin --sbindir=/home/maz/freetz-trunk/toolchain/target/bin --datadir=/home/maz/freetz-trunk/toolchain/target/share/ --libdir=/home/maz/freetz-trunk/toolchain/target/lib --libexecdir=/home/maz/freetz-trunk/toolchain/target/libexec/ --includedir=/home/maz/freetz-trunk/toolchain/target/include/ --oldincludedir=/home/maz/freetz-trunk/toolchain/target/include/ --build=i386-linux-gnu --target=mipsel-linux --host=mipsel-linux

Das setzen der $PATH-Variable ist auf jedenfall Vorraussetzung, wie du bereits festgestellt hast. Ansonsten wird der mipsel-linux-gcc beim Kompilieren nicht gefunden.

Programme bekommt man eine Spur kleiner, wenn man als CFLAG noch folgendes angibt:

make CFLAGS="-Os -s -pipe -march=4kc -Wa,--trap"

und danach noch ein 'mipsel-linux-strip' ausführt:

mipsel-linux-strip --remove-section={.comment,.note,.pdr} myapp

 

[RalfFriedl]

Das fertige Programm läuft auch bereits auf der FritzBox.

Hast Du es inzwischen für die Box übersetzt, oder läuft das Programm aus dem oberen Beitrag, das Du mit dem normlen Compiler erstellt hast?

 

[febo]

Hi,

wahrscheinlich hab auch ich etwas überreagiert. Was solls, solang man drüber redet

Übersetzt habe ich das Programm nicht, dazu habe ich leider nicht die notwendige Erfahrung. Ich bin eher bei Web spezifischen Sprachen wie PHP, JavaScript u.s.w zu Hause.

Nachdem ich das Makefile mit den notwendigen Pfaden versehen und das zuvor compilierte Programm entfernt hatte, lief auch make wieder durch. Ist ja auch klar, sonst würde er ein bestehendes Programm ja auch überschreiben müssen.

Habe das Programm dann mittels FTP auf die Box geschoben und gestratet.

Folgende Ausgabe erhalte ich:

nethostfs v1.5 starting up, maximum of 20 PSPs allowed
Listening for incoming connections...

Soweit keine Parameter übergeben werden lauscht das Programm am Port 7513 auf eingehende Verbindungen. Nun habe ich an einem Linux Rechner über die Shell nmap 192.168.1.45 eingegeben, um zu sehen ob dieser Port offen ist. Leider nicht.

Momentan weiß ich da nicht so richtig weiter. Hast die vielleicht eine Idee was ich noch überprüfen sollte?

[EDIT]: Habe mal einen anderen Port ausprobiert (86) und siehe nmap findet diesen Port und nethostfs zeigt auch eine eingehende Verbindung. Nun muss ich nur noch eine Verbindung mit der PSP hinbekommen.

Gruß febo

 

[RalfFriedl]

In der Voreinstellung überprüft nmap nicht alle Ports, sondern nur bestimmte Ports, die häufig genutzt werden. Du kannst mit der Option -p bei nmap festlegen, welche Ports gescannt werden sollen. Also zum Beispiel -p1-65535 für alle Ports oder -p7513 um nur den einen Port zu prüfen.
Wenn es nur um einem Port geht, kann man auch gleich mit telnet eine Verbindung zu dem Port aufbauen.
Vermutlich ist es einfacher, wenn Du das Programm auf dem Standard-Port läuft.

 

[febo]

Hi RalfFriedl,

vielen Dank für den Tipp. Du hattest recht, der Prot ist nun auch offen. Leider scheinen die Probleme nun bei der PSP zu liegen. Habe schon in einigen PSP Forum darüber gelesen, dass es ständig Probleme mit der WLAN Anbindung zu einem Rechner über nethostfs gibt.

Andere Frage:

Wie kann ich Programme permanent bei einem Neustart der Box ebenfalls neu starten lassen. Ich hatte gelesen, man könnte im Ordner /var/tmp/flash ein Script namens debug.cfg und dort die entsprechenden Befehle ausführen. Leider ist nach einem Neustart der Box diese Datei wieder weg. Obwohl ich las, das dies im genannten Ordner nicht der Fall sein sollte.

Hat jemand einen Link zu einem Beitrag für mich?

Gruß febo

 

[RalfFriedl]

Der Pfad heißt /var/flash/debug.cfg, ohne tmp. Dort sollte schon eine Datei vorhanden sein. Zum Bearbeiten kann man diese Befehle verwenden:

>> /var/flash/debug.cfg
nvi /var/flash/debug.cfg

Die erste Zeile sollte nur beim ersten Mal notwendig sein, aber auch sonst nicht weiter stören.

 

[febo]

Hi RalfFriedl,

gebe ich den Befehl >> /var/flash/debug.cfg ein erhalte ich folgende Meldung:

-sh: cannot create /var/flash/debug.cfg: Bad address

Die Datei ist aber vorhanden, wie du ja sagtest.

gebe ich den Befehl nvi /var/flash/debug.cfg ein öffnet er eine neue leere Datei, weil er die gewünschte anscheinend nicht findet oder nicht öffnen kann.

Im mc (ich hab ihn mal mit installiert) wird die Datei mit einem - vor dem Namen und in lila, rosa (oder so) angezeigt. Auch mc kann diese Datei nicht öffnen. mc sagt:

cannot open file for reading: debug.cfg

Die Datei gehört aber root und die rechte stehen auf rwxr-xr-x. Es müsste doch also eigentlich gehen??! MAN, ich kriege hier aber garnichts hin heute...

Gruß febo

 

[RalfFriedl]

Die Datei hat normalerweise keinen Inhalt, das ist also so schon richtig.
Versuch mal, ob beim Speichern mit nvi der Inhalt erhalten bleibt. Wenn nicht, dann folgendes, jedes nacheinander, bis es funktioniert. Wenn es geht, dann berichte auch, welche Variante funktioniert hat.

echo >> /var/flash/debug.cfg
> /var/flash/debug.cfg
echo > /var/flash/debug.cfg

Die letzten beiden Zeilen sollte man auf jeden Fall nur verwenden, wenn die Datei leer ist, weil damit der Inhalt überschrieben wird.

Und als Hintergrund-Info: bei der Datei handelt es sich um eine Geräte-Datei, mit der auf den Flash-Bereich der Box zugegriffen wird. Mit einigen, aber nicht allen, Versionen von cp auf der Box gibt es Probleme, wenn man damit die Datei kopieren will. Das sicherste ist daher, zum Kopieren cat zu verwenden (was im Skript nvi auch verwendet wird).

 

[febo]

Hi RalfFriedl,

Geräte Dateien, also vergleichbar mit denen auf einem Linux System im /dev Ordner?

Mit dem zweiten von dir genannten Befehl hat es funktioniert. nvi öffnet die Datei nun auch ohne Fehlermeldung.

Vielen Dank

Gruß

febo

 

[RalfFriedl]

Ja, Geräte-Dateien wie die, die normalerweise in /dev stehen.

Das Dateisystem /var ist nur im RAM und der Inhalt geht beim Ausschalten verloren. Die Geräte-Dateien in /var/flash greifen aber auf einen Bereich im Flash zu und der Inhalt steht auch nach dem nächsten Neustart zur Verfügung. Deswegen das teilweise etwas seltsame verhalten dieser Dateien.

 

[DO4ARM]

Hmm,

habe langsam den Verdacht das es an der Laborversion FW xx.04.78-15696 vom 16.11.09 liegt, dass diese 3 Versuche bei mir nicht funktionieren.

Die debug.cfg will einfach leer bleiben, voll zum Verzweifeln.

Haben die bei AVM da etwas geändert um einen es noch schwerer zu machen die debug.cfg zu ändern?