Wie kompiliert man z.B. camd2

Beitrag von **MattisBLN** » Dienstag 25. Mai 2004, 16:28

Gibt es jemand der mit einfachen Worten sagen kann, wie man nur das camd2 einzeln kompilieren kann?

Suse 9.0, cvs ist geladen, make all schlägt fehl...

Wäre echt dankbar!

Matthias

Beitrag von **Npq** » Dienstag 25. Mai 2004, 17:37

In einfachen Worten "make tuxbox_tools" im CDK-Verzeichnis.

Wenn bei dir make all aber nicht geht gibt's keine einfachen Worte. Dann wird's komplizierter.

Beitrag von **MattisBLN** » Dienstag 25. Mai 2004, 18:12

Danke erstmal.

ich habe jetzt nochmal folgendes eingegeben:

cdk>./autogen.sh
cdk>./configure --enable-maintainer-mode --prefix=/home/mattis/dbox2 --with-cvsdir=/home/mattis/tuxbox-cvs

cdk>make tuxbox_tools

Das Ganze endet mit folgenden Zeilen:

Code: Alles auswählen

: /home/mattis/tuxbox-cvs/cdk/build_glibc/libc.a
cd /home/mattis/tuxbox-cvs/cdk/build_glibc && /home/mattis/dbox2/cdk/lib/gcc-lib/powerpc-tuxbox-linux-gnu/3.3.3/../../../../powerpc-tuxbox-linux-gnu/bin/ar cruv libc_nonshared.a `cat csu/stamp.oS iconv/stamp.oS iconvdata/stamp.oS locale/stamp.oS localedata/stamp.oS assert/stamp.oS ctype/stamp.oS intl/stamp.oS catgets/stamp.oS math/stamp.oS setjmp/stamp.oS signal/stamp.oS stdlib/stamp.oS stdio-common/stamp.oS libio/stamp.oS dlfcn/stamp.oS malloc/stamp.oS string/stamp.oS wcsmbs/stamp.oS timezone/stamp.oS time/stamp.oS dirent/stamp.oS grp/stamp.oS pwd/stamp.oS posix/stamp.oS io/stamp.oS termios/stamp.oS resource/stamp.oS misc/stamp.oS socket/stamp.oS sysvipc/stamp.oS gmon/stamp.oS gnulib/stamp.oS wctype/stamp.oS manual/stamp.oS shadow/stamp.oS po/stamp.oS argp/stamp.oS crypt/stamp.oS linuxthreads/stamp.oS resolv/stamp.oS nss/stamp.oS rt/stamp.oS conform/stamp.oS debug/stamp.oS linuxthreads_db/stamp.oS inet/stamp.oS hesiod/stamp.oS sunrpc/stamp.oS nis/stamp.oS nscd/stamp.oS streams/stamp.oS login/stamp.oS soft-fp/stamp.oS elf/stamp.oS stamp.oS`
a - csu/elf-init.oS
a - stdlib/atexit.oS
a - io/stat.oS
a - io/fstat.oS
a - io/lstat.oS
a - io/mknod.oS
a - io/stat64.oS
a - io/fstat64.oS
a - io/lstat64.oS
: /home/mattis/tuxbox-cvs/cdk/build_glibc/libc_nonshared.a
powerpc-tuxbox-linux-gnu-gcc   -nostdlib -nostartfiles -r -o /home/mattis/tuxbox-cvs/cdk/build_glibc/libc_pic.os \
 -Wl,-d -Wl,--whole-archive /home/mattis/tuxbox-cvs/cdk/build_glibc/libc_pic.a
collect2: ld returned 1 exit status
make[3]: *** [/home/mattis/tuxbox-cvs/cdk/build_glibc/libc_pic.os] Fehler 1
make[3]: Leaving directory `/home/mattis/tuxbox-cvs/cdk/glibc-2.3.2'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/home/mattis/tuxbox-cvs/cdk/build_glibc'
make[1]: *** [.deps/glibc] Fehler 2
make[1]: Leaving directory `/home/mattis/tuxbox-cvs/cdk'
make: *** [.deps/bootstrap] Fehler 2
mattis@fanclub-l:~/tuxbox-cvs/cdk>

camd2 entsteht nicht (wo müsste das denn sein? Über die Suchfunktion von Konqueror jedenfalls nicht zu finden).

Hast du eine Idee, woran es liegen kann?

danke! Matthias

Beitrag von **rasc** » Dienstag 25. Mai 2004, 18:56

Versionen der autoconf, etc. mal gecheckt? (siehe cdk/doc)

Beitrag von **MattisBLN** » Dienstag 25. Mai 2004, 19:43

Meine Konfiguration:

Suse 9.0 frisch installiert.

cvs - 1.11.6-54

autoconf - in Suse ist 2.57 enthalten, hier im Forum gabs n Link auf ein RPM, Yast zeigt nun, dass 2.57 mit 2.59-0.gvb.1 installiert ist.

automake - 1.76-41
libtool - 1.5-80
gettext - 0.12.1-71
make - 3.80-96
texinfo - 4.5-88
tar - 1.13.25-199
bzip2 - 1.0.2-224
gunzip - 1.3.5-47
patch - 2.5.9-52
ncurses - 5.3-110
ncurses-devel - 5.3-110
gcc - 3.3.1-24
gcc-c++ - 3.3.1-24 (g++ oder gpp kennt Suse nicht, liegt da der Fehler?)
flex - 2.5.4a-195
bison - vergessen nachzusehen, ist aber installiert
pkg-config 0.15.0-104
wget - 1.8.2-301

Hat hier noch jemand Suse?

Danke nochmal,
Matthias

Beitrag von **rasc** » Dienstag 25. Mai 2004, 20:59

ich habe Suse 8 und habe alle make-tools nach-compiliert...

Beitrag von **MattisBLN** » Dienstag 25. Mai 2004, 21:21

das ist jetzt mindestens mein dritter Anlauf, ich habs mit Mandrake probiert, mit verschiedenen Suse-Versionen und mit Knoppix, aber das make all stirbt jedes mal ab...

Beitrag von **Npq** » Dienstag 25. Mai 2004, 23:33

Blöde Sache, naja, make ist normalerweise nicht dran schuld, sondern im Beispiel oben ist es z.B. der ld, also der Linker, der aussteigt. Leider steht da nicht wieso was eher seltsam ist.

Genug Platz auf der Festplatte ist aber vorhanden?

Gerade mit Knoppix müßte es gehen, denn das basiert auf Debian.

Ich hab's selber bereits unter Debian und Gentoo probiert und bei beiden keine Probleme gehabt. Debian Woody ist allerdings mittlerweile von den Autotools zu alt, da muß man auf Sid upgraden oder halt gezielt nachinstallieren.

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 07:59

Wieviel Speicherplatz benötigen den cvs und cdk nach vollständiger Compilation insgesamt? Ich hab für Suse eine rund 4 GB große Partition.

Darauf sind jetzt, nachdem das cvs drauf ist, noch 610 MB frei. Edit: Jetzt 1,6 GB

Ich hab jetzt den Ordner dbox2 nochmal gelöscht und nur make tuxbox_tools aufgerufen, jetzt bricht make ab mit

"Unbekannte Option -mppc"
make[4]***[crtbegin.o] Fehler 1
make[4] Leaving directory /home/mattis/tuxbox-cvs/cdk/build_bootstrap_gcc/gcc

Nochmal ganz von vorne?
Kann man von dem ganzen Shell-Vorgang ein Log-File erzeugen?

Edit:
nach einem make distclean ist das make tuxbox-tools jetzt deutlich weiter gekommen aber dann leider abgebrochen, weil ich hier zurzeit keine Internetverbindung habe. Momentan sind auf meiner Partition wieder 1,6 GB frei. Probier es heute Nachmittag nochmal...

Danke weiterhin

Matthias

Beitrag von **Npq** » Mittwoch 26. Mai 2004, 12:57

Das schwankt schonmal, aber 1 GB sind's auf jeden Fall.

Während des Kompilierens werden auch noch zusätzliche Dateien angelegt, die hinterher wieder entfernt werden, das kann also zwischendurch noch größer sein als am Ende.

Die glibc ist ein ziemlicher Brocken, während sie kompiliert wird, legt sie 350(!) MB an zusätzlichen Dateien an. Diese werden zwar hinterher entfernt, aber sie müssen zwischendurch vorhanden sein.

Nochwas, im Normalfalle wird für den root-account immer ein gewisser Prozentsatz an Plattenspeicher freigehalten (damit ein User nicht das System zumüllen und zum Absturz bringen kann). Sagen wir mal, der Wert wäre bei 10%. Bei 4 GB wären das also ca. 410 MB. Wenn du also nachschaust und 610 MB als frei angegeben werden, so wären davon in Wirklichkeit nur 200 MB nutzbar (wir bauen schließlich NIEMALS als root).

So 2-3 GB an Platz sollte man also besser schon einplanen, um keine Probleme zu bekommen.

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 14:05

Danke schonmal für die fundierten Infos. Mal sehen, ob's nachher mit Internetverbindung besser läuft.

Ich hab für die Suse-Installation insgesamt etwas über 5 GB frei gemacht, davon hat sich Suse dann erstmal 1 GB für Swap genommen, hab ich jetzt im nachhinein aber auf 500 oder so reduziert. Vielleicht installier ich das Suse-Paket halt noch zum 10. Mal neu mit Minimalausstattung... vielleicht auch ohne KDE?

Mir gehts ja einfach erstmal darum, dass das ganze CDK so wie überall beschrieben einfach durchläuft. Dann kann ich ernsthaft darüber nachdenken, mich da mal einzuarbeiten und vielleicht mal irgendwas davon zu verstehen...

Wird der zusätzliche "Zwischendurch-Bedarf" bei jedem Make-Durchlauf fällig, oder werden nur die Teile neu compiliert, die wirklich geändert werden und beim nächsten Durchlauf fällt dann nicht mehr soviel Zusatzbedarf an?

Ich bekomme übrigens auch beim make tuxbox-tools (aber auch bei make all) hunderte von Warning-Meldungen, die aber so schnell durchlaufen, dass man nicht lesen kann. Lässt sich das irgendwie protokollieren? ein >protkoll.txt hat nur einen kleinen Teil ins Textfile geschrieben, nach kurzer Zeit kamen die Meldungen doch wieder in die Shell...

Gruß, Matthias

Beitrag von **Npq** » Mittwoch 26. Mai 2004, 16:06

Die kommen nicht auf stdout, sondern auf stderr, muß man umleiten, am besten beides, geht so:

make all >errors.txt 2>&1

Es wird immer nur das neu kompiliert was geändert wurde. Jedesmal eine Stunde zu warten bis glibc und gcc kompiliert sind wäre doch ein bißchen viel, wenn man zum Debuggen mal ein "printf()" eingebaut hat.

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 16:41

Die drei Warnungen bei ./configure (irgendwas mit CANONICAL) sind erstmal zu ignorieren, oder?

Was bewirkt eigentlich make distclean?

Edit: Noch ne Frage: Wenn ich nach make tuxbox_tools ein make all mache, wird dann was doppelt compiliert? Oder nimmt man dann besser make rebuild-flash, selbst wenn noch nie ein make all gelaufen ist?

Edit: Und noch eine: Woher weiss das System, welche Datei ich geändert hab, um nur diese neu zu compilieren? Was gebe ich ein, um so ein "Update" zu machen? Muss ich jedesmal ./autogen.sh und ./configure aufrufen, bevor ich neu compiliere?

Gruß, Matthias

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 17:37

Also erstmal: Es lag offenbar wirklicm Speicherplatz, zwischenzeitlich war der Plattenplatz auf 24 MB runter und dann wieder hoch bis über 1 GB. Offenbar hat es deshalb bei mir noch NIE geklappt...

Vielleicht sollte so ein Hinweis mal in die INSTALL.en aufgenommen werden, dass man zur Installation des CDK im ersten Durchlauf ein Minimum von rund 2-3 GB freiem Plattenplatz im Home-Verzeichnis benötigt.

Jetzt bricht make tuxbox_tools ab mit dem Fehler

bin/sh: line 1: cd: no/misc/libs: Datei oder Verzeichnis nicht gefunden
make: *** [no/misc/libs/config.status] Fehler 1

Und nu?

Gruß, Matthias

Beitrag von **Npq** » Mittwoch 26. Mai 2004, 17:58

Die Warnungen entstehen irgendwie durch falsche Reihenfolge/Inkludierung, hab ich mir noch nicht genauer angesehen.

Das Ausführen von autogen.sh erzeugt das configure-Skript
Das Ausführen vom configure-Skript erzeugt dann die entsprechenden Makefiles.

Die Autotools sind aber mittlerweile so intelligent, daß das Makefile bei eingeschaltetem Maintainer-Mode ("--enable-maintainer-mode") automatisch erkennt, wenn eine Änderung vorgenommen wurde, so daß man "eigentlich" nie autogen.sh oder configure ein zweites Mal aufrufen braucht. Praktisch kann's aber doch passieren, wenn man z.B. nen Fehler im Makefile.am eingebaut hat und das Makefile nicht mehr läuft.

Woher make weiß was er wann wie neubauen soll ist von vielen abhängig, im einfachsten Fall von den Dateien im .deps-Verzeichnis. Im Grunde genommen schaut er nach, ob sich eine Abhängigkeit geändert hat. Das können aber so viele verschiedene Dinge sein, daß ich dazu einen Blick ins Manual von make empfehlen würde.

Ich hab selber die Erfahrung gemacht, daß man's erst wirklich versteht, wenn man damit selber gearbeitet hat, vorher ist das alles sehr, sehr abstrakt.

Das mit dem "no" kommt dann vor, wenn man das cvs-Verzeichnis nicht richtig angegeben hat und er die Unterverzeichnisse nicht findet. Ist fast immer ein Tippfehler bei dem "--with-cvsdir=".

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 18:04

Aber er hat vorher rund 40 Minuten alles mögliche gemacht und erst mittendrin abgebrochen. Vorher hat er ja auch alles gefunden sodass ich denke, dass das cvs-dir richtig angegeben war... Oder ist das cvs-dir in einem der Befehle in einem der make-Files falsch, d. h. er übernimmt meine lokale Einstellung irgendwie nicht aus dem configure-Aufruf?

Momentan läuft mal ein make-all, hab vorher ./configure und ./autogen NICHT nochmal aufgerufen...

Ich meinte nur, was / welches make-Ziel muss ich denn eingeben, wenn ich in den tuxbox-tools was ändere (an einem .c-Source-File). Das cvs selber ist doch erst wieder interessant, wenn ich Dateien als "Dev" wieder einchecken möchte bzw. mein cvs mit dem allgemeinen cvs wieder update, oder?

Sorry, aber insgesamt ist die Dokumentation zum cdk relativ dünn für jemanden, der sich nich damit auskennt...

Vielleicht noch eine dumme Frage: was habe ich eigentlich, wenn make all durchgelaufen ist. Bisher war ich der Ansicht, dass ich dann die Basisdateien für ein Image für die dbox habe. Aber da ensteht noch mehr, oder? Was ist das "cdk" genau?

Danke für deine Geduld!

Matthias

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 18:16

Make all endet nun mit:

Code: Alles auswählen

        make install PREFIX=/home/mattis/dbox2/cdkroot
make[1]: Entering directory `/home/mattis/tuxbox-cvs/cdk/libdvb-0.5.3'
make -C libdvb main
make[2]: Entering directory `/home/mattis/tuxbox-cvs/cdk/libdvb-0.5.3/libdvb'
powerpc-tuxbox-linux-gnu-g++ -I. -I../include -I../../include -mcpu=823 -mmultiple -mstring -meabi -pipe -O2 -g3 -gdwarf-2 -Ino/dvb/include -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c devices.cc
In file included from devices.cc:1:
../include/devices.hh:14:32: linux/dvb/frontend.h: No such file or directory
In file included from devices.cc:1:
../include/devices.hh:48: error: 'fe_spectral_inversion_t' is used as a type,
   but is not defined as a type.
devices.cc:2:32: linux/dvb/frontend.h: No such file or directory
devices.cc:10: error: syntax error before `[' token
devices.cc: In function `std:::empty:& operator<<(std:::empty:&, Transponder&)
   ':
devices.cc:125: error: `FE_QPSK' undeclared (first use this function)
devices.cc:125: error: (Each undeclared identifier is reported only once for
   each function it appears in.)
devices.cc:127: error: `FE_QAM' undeclared (first use this function)
devices.cc:135: error: `FE_OFDM' undeclared (first use this function)
devices.cc:144: error: 'class Transponder' has no member named 'inversion'
devices.cc:145: error: `INVERSION_OFF' undeclared (first use this function)
devices.cc:148: error: `INVERSION_ON' undeclared (first use this function)
devices.cc:151: error: `INVERSION_AUTO' undeclared (first use this function)
devices.cc: In function `std::istream& operator>>(std::istream&, Transponder&)
   ':
devices.cc:299: error: `FEC_AUTO' undeclared (first use this function)
devices.cc:300: error: 'class Transponder' has no member named 'inversion'
devices.cc:399: error: 'class Transponder' has no member named 'inversion'
devices.cc:399: error: `invset' undeclared (first use this function)
make[2]: *** [devices.o] Fehler 1
make[2]: Leaving directory `/home/mattis/tuxbox-cvs/cdk/libdvb-0.5.3/libdvb'
make[1]: *** [libdvb/libdvb.a] Fehler 2
make[1]: Leaving directory `/home/mattis/tuxbox-cvs/cdk/libdvb-0.5.3'
make: *** [.deps/libdvb] Fehler 2
mattis@fanclub-l:~/tuxbox-cvs/cdk>

Ich weiss es nicht...

Matthias

Beitrag von **Npq** » Mittwoch 26. Mai 2004, 19:52

Naja, Grundlagen für CVS und Autotools gehören wohl kaum in eine Entwicklungsumgebung. Das sind einfach Standardtools, die genauso benutzt werden wie überall.

Das CDK ist ja nicht für Enduser gedacht, sondern für Entwickler und wenn die nicht wissen, wie man die entsprechenden Tools anwendet, dann müssen sie es lernen.

Dein Problem ist immer noch "-Ino/dvb/include" bzw. die fehlende Verzeichnisangabe.

Das taucht erst auf, wenn er auf die CDK-Sourcen zugreift (weil zuerst ja die Entwicklungsumgebung gebaut wird). Die 3rd-Party-Dinge wie gcc/glibc etc. liegen natürlich nicht im CDK, sondern werden als Archiv heruntergeladen und dann entpackt und evtl. gepatched und hinterher wieder gelöscht.

Wenn du im CDK-Verzeichnis mal "./config.status --recheck" eingibst, steht am Ende, ob er die ganzen Verzeichnisse gefunden hat. Wen da "no" steht, dann hast du etwas falsch angegeben oder du hast einen Bug gefunden.

Zu sagen was man für welches Programm angeben muß ist schwierig, da muß man sich in den Makefiles für ansehen.

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 20:39

Es ist ja nicht so, dass ich nichts lernen will. Es wird einem nur leider insgesamt nicht sehr leicht gemacht, sich da ein zu fummeln. Du bist ehrlich gesagt der Erste, der sich die Mühe macht, mir mal ein paar Fragen zumindest ansatzweise zu beantworten.

Ich kann verstehen, dass hier viele ihre Freizeit damit aufwenden, an dem Projekt zu programmieren und ich verstehe auch, dass sich viele über die sicher ungerechtfertigte Erwartungshaltung einiger Anwender aufregen. Aber es ist auf der anderen Seite auch wirklich schwer, vom Anwender zum Entwickler zu werden. Und ich denke einfach, dass sich dieses Verhältnis entspannen ließe, wenn die Dokumentationen ein paar mehr Links auf Infos zu den Standardtools und zum CDK enthielten. Wenn vielleicht einfach ein Entwickler, der diesen ganzen Werdegang gerade hinter sich, mal umreißen würde, wie er sich da durchgeschlagen hat. Welche Tools er unter Linux verwendet, welche Literatur ihm geholfen hat, welche Links im Internet ihn auf die richtige Spur gebracht haben usw..

Solange es sowas nicht gibt wird das hier nie aufhören, dass Menschen wie ich erstmal hilflos fragen und dann entweder irgendwann entnervt aufgeben oder zu einem frech fordernden Nur-noch-Anwender mutieren.

Ich hab meinen ersten Versuch vor rund einem Jahr gestartet, aber Entwickler wie einer, der mittlerweile wohl aufgehört hat, haben mir in kurzen knappen Antworten klar gemacht, dass ich einfach nicht würdig bin, mit hilfreichen Infos versorgt zu werden, solange ich nicht schon mal wenigstens einen Linuxkernel selber compiliert hab (sicher überspitzt dargestellt, aber übertreiben hilft verdeutlichen)... Also hab ichs aufgegeben. Dank deiner Hilfe bin ich nun wenigstens erstmal dahinter gekommen, dass es bisher schonmal nur am Festplattenplatz gescheitert ist.

Momentan schau ich wie das berühmte Schwein ins Uhrwerk. Ich hab jetzt nochmal ganz von vorne angefangen, momentan läuft ein make all schon seit fast einer Stunde. Ich sehe zwischendurch hunderte von Warnungen durchlaufen, irgendwas von "inline from here" o. ä. und von fehlenden Operanden, aber scheinbar sind es zunächst nur Warnungen, die nicht zum Abbruch führen. Keine Ahnung, ob bereits die erste Warnung dazu führt, dass am Ende doch nichts klappt - woher auch...

Ich danke dir jedenfalls wirklich sehr für deine Hilfe soweit. Ich hab jetzt nochmal alles von vorne angefangen, nachdem ich die root-Partition auf 5,3 GB erweitert hab und momentan läuft ein make all seit rund 1,5 Stunden, ist jetzt bei enigma/lib, scheint also erstmal ganz gut auszusehen. Melde mich ggf. bei der nächsten Fehlermeldung wieder

Matthias

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 21:20

So, offenbar ist make all jetzt durchgelaufen.

Interessanterweise wurde sowohl im dbox2/cdkroot als auch im tuxbox-cvs/apps/tuxbox/tools/camd - Verzeichnis jeweils eine camd2 erstellt mit 130 kb, dass ist ja nun deutlich mehr, als die bekannte camd2...

Nachdem ich eine der Quelldateien im cvs-Verzeichnis bearbeitet hab, macht make all gar nichts bzw. zunächst heisst es "ziel nicht gefunden" und nach ./autogen und ./configure macht make all nichts. War da noch was mit touch, womit man make all dazu bekommt, die geänderten Bereiche neu zu compilieren?

Der Befehl "make flash-all" aus dem readme-flash.de funktioniert gar nicht. Ziel nicht gefunden. Muss ich den woanders ausführen als im tuxbox-cvs/cdk ?

Danke weiterhin!

Matthias

Beitrag von **Npq** » Mittwoch 26. Mai 2004, 22:05

Ja, ich kenn' das Problem ja selber noch.

Ich meinte damit auch, daß sich hier kaum jemand hinsetzen wird und groß z.B. die Autotools erklärt, weil das zu komplex ist und man dafür schon ein Tutorial erstellen müßte und das gibt's an vielen Stellen.

Die Autotools sind mitsamt Dokumentation bei http://www.gnu.org zu finden. Richtig gute Tutorials weiß ich leider gerade keine, die meisten beschränken sich entweder auf die einfachen Dinge oder handeln Spezialthemen ab.

Was dem CDK fehlt, ist eine ordentliche Beschreibung der inneren Struktur. Das Makefile im CDK-Verzeichnis führt selber wieder verschiedene configure-Skripte in Unterverzeichnissen aus und prüft deswegen als Abhängigkeit zum Teil nur die config.status-Datei. Und wenn die sich nicht ändert (weil nicht neu konfiguriert wurde), dann baut er auch nicht neu.

Was man machen kann, ist, sich die powerpc-Tools in den Pfad zu legen und dann in den entsprechenden Unterverzeichnissen direkt die Makefiles ausführen. Configuren kann man da allerdings nicht gut, weil man dann die richtigen Optionen angeben muß (CPU etc.).

Die Dateien im CDK sind alle ungestrippt, d.h. sie enthalten noch sämtliche Debuginformation. Dafür gibt's das Programm powerpc-tuxbox-linux-gnu-strip.

Beitrag von **MattisBLN** » Mittwoch 26. Mai 2004, 22:13

Also wenn ich dich richtig verstehe

- ist das camd2 so groß, weil inkl. Debug-Infos compiliert
- könnte man die Debug-Infos mit dem genannten Tool entfernen
- wenn man die Tools im Pfad hat, kann man das Makefile aufrufen

Reicht es, den Ordner aus dem cdk-Verzeichnis in den Pfad zu legen?

Das Problem mit make flash-all hat sich erledigt, mein Drucker hatte die --with-targetruleset - Option verheimlicht.

Wo finde ich mkjffs2 als rpm für Suse? mkcramfs und fakeroot hab ich gefunden, für fakeroot fehlt aber noch irgendwas (wird fakeroot überhaupt gebraucht?) ...

Gruß, Matthias

Beitrag von **Npq** » Donnerstag 27. Mai 2004, 02:57

Ja, wobei ich schon gar nicht mehr genau weiß, ob man das mit dem Pfad nicht nur bei den Treibern brauchte. Probier's einfach mal aus, mehr als eine Fehlermeldung kann ja nicht kommen.

Zum Image Erstellen wissen andere besser Bescheid, was man wofür genau braucht, das ist nicht so sehr mein Gebiet.

Beitrag von **MattisBLN** » Donnerstag 27. Mai 2004, 06:57

Also, nun bin ich wieder zwei Schritte weiter:

Ich habe einfach auf alle Dateien unter /home/mattis/dbox2/cdk/bin eine Verknüpfung nach /home/mattis/bin erstellt, und schon kann ich auch einzelne Programme in ihrem cvs/apps-Verzeichnis oder wo auch immer mit make erstellen.
Zudem ist es mir gelungen, den strip-Befehl aus dem cdk anzuwenden, welche Option ist hier zu empfehlen? Ich habe jetzt erstmal nur --strip-all verwendet. Reicht das, um die kleinstmögliche lauffähige Datei zu erzeugen?

Ich frage mich immer noch, wie ihr Entwickler mit wenigen Handgriffen alle geänderten Programmteile neu compiliert, nachdem ihr euer cvs mit dem öffentlichen cvs upgedatet habt (cvs up -dP). Wenn du sagst, dass make all zB. nichts tut, solange die Konfiguration unverändert bleibt...?

Muss man die Versionsnummer in einer .c-Datei hochzählen, damit make all was merkt? Oder muss die .c-Datei mit einem Tool aus dem cdk statt mit einem anderen Editor bearbeitet werden?

Zum cdk hab ich mir auch nochmal Gedanken gemacht. Liege ich richtig mit folgender Beschreibung? ->

CDK: Da auf einem anderen als dem Zielsystem programmiert und compiliert wird (zB cygwin oder Linux), muss der Compiler (hier gcc) so angepasst werden, dass er Code für das Zielsystem erstellt. Daher muss als erstes das komplette cdk compiliert werden um Compiler und Tools für das Zielsystem zu haben, mit denen dann über make die ausführbaren Dateien für das Zielsystem (dbox) erstellt werden können.

Gruß, Matthias

Beitrag von **Npq** » Donnerstag 27. Mai 2004, 14:18

Ich meinte "make all" im CDK-Verzeichnis. Aber ich persönlich arbeite eher selten aus dem Verzeichnis raus, sondern meist in den entsprechenden Unterverzeichnissen.

Für jedes Unterverzeichnis gibt's ein Makefile, demzufolge kann man make auch überall aufrufen.

Make überprüft z.B. das Datum der Dateien und berücksichtigt Abhängigkeiten, wenn du eine include-Datei änderst, dann werden auch alle abhängigen Sources neu übersetzt.

Und ja, Compiler, Linker, Assembler etc. müssen natürlich Code für die jeweilige Plattform erzeugen. Dabei muß übrigens nichts angepaßt werden, sondern das können die von Hause aus, man muß es nur beim Kompilieren der Tools angeben. Beim PC ist es dabei dann einfach so, daß Host (wo wird's mal ausgeführt?), Build (wer soll's übersetzen?) und Target (wofür soll Code erzeugt werden?)-System übereinstimmen.