sumversion meldet immer Fehler (‘PATH_MAX’ undeclared)

[schack]

Hallo zusammen,

immer wenn ich freetz kompiliere, bekomme ich folgende Fehlermeldungen:
scripts/mod/sumversion.c: In function ‘get_src_version’:
scripts/mod/sumversion.c:384: error: ‘PATH_MAX’ undeclared (first use in this function)
scripts/mod/sumversion.c:384: error: (Each undeclared identifier is reported only once
scripts/mod/sumversion.c:384: error: for each function it appears in.)
scripts/mod/sumversion.c:384: warning: unused variable ‘filelist’
make[3]: *** [scripts/mod/sumversion.o] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[2]: *** [scripts/mod] Fehler 2
make[1]: *** [scripts] Fehler 2
make[1]: Verlasse Verzeichnis '/home/ben/download/freetz-trunk/source/ref-8mb_26-7270/kernel/kernel_8mb_26_build/kernel/linux-2.6.19.2'
make: *** [source/ref-8mb_26-7270/kernel/kernel_8mb_26_build/kernel/linux-2.6.19.2/vmlinux.eva_pad] Fehler 2


Ich ändere bis jetzt immer sumversion.c und füge die Deklaration für PATH_MAX hinzu. Dann gehts. Aber es nervt das jedesmal zu ändern.
Habt jemand anders auch das Problem?
Woran kann es liegen?

Ach, btw: ich kompiliere unter Ubuntu 8.10

Gruß

Ben

 

[McNetic]

Das sollte eigentlich definiert sein; hast Du mal einen neuen Checkout gemacht und es dann nochmal probiert?

 

[RalfFriedl]

Bei mir wird PATH_MAX in /usr/include/linux/limits.h definiert.

 

[schack]

Das sollte eigentlich definiert sein; hast Du mal einen neuen Checkout gemacht und es dann nochmal probiert?

Ja, ist alles ganz frisch ausgecheckt.

 

[schack]

Bei mir wird PATH_MAX in /usr/include/linux/limits.h definiert.

Ja ist bei mir da auch drin:
#define PATH_MAX 4096 /* # chars in a path name including nul */

Aber trotzdem die Fehlermeldung.
Hab ich auf zwei verschiedenen Rechnern mit ubuntu 8.10.

 

[Silent-Tears]

Dann würde ich sagen, da es bie mir mit dem stable Ubuntu funktioniert, hat Ubuntu 8.10 ein Problem. Kein wunder, es soll ja auch erst im Oktober veröffentlich werden, oder?

 

[schack]

Muß wohl so sein. - Aber nervt trotzdem...

Ja, sind die normalen Release-Zyklen: April und Oktober.
8 = 2008, . 10 = Oktober

Ansonsten läuft's aber sehr gut.

 

[Silent-Tears]

Was nervt? Setz dir ne virtuelle Maschine darin auf, um ein LTS-Ubuntu zu nutzen. Das hilft dir beim Imagebaune und uns Probleme auszuschliessen, die manche haben, die so nicht reproduzierbar sind.

 

[schack]

Für ne VM hab ich leider kein Platz mehr. Und finde ich zu aufwendig.
Da editier ich lieber selbst eine Textdatei.

Da ich das Problem schon seit anfang an (einige Wochen) mit freetz und ubuntu hab, dachte ich es hat vl. auch jemand anders und könnte mir vl. helfen.

 

[Silent-Tears]

Ich glaube, es findden sich wirklich wenige, die die 8.10 drauf haben. Die ist an vielen Stellen so Buggy (auch im Ubuntuforum), dass man da meiner Meinung nach ein wneig die Finger von weglassen sollte noch. Aber: Dies ist meine persönliche Meinung.

 

[RalfFriedl]

Da editier ich lieber selbst eine Textdatei.

Wenn Du schon Beta-Software verwendest, dann solltest Du bei Fehlern aber auch versuchen, die Ursache herauszufinden und zu melden und nicht mit einer Notlösung den Fehler umgehen.

 

[coolphoenix]

ich habe den fehler auch auf einem gentoo x86_64 (mit einigen ~amd64-packeten), in einer 32bit-gentoo-chroot-umgebung läuft's dagegen ohne probleme.

 

[Silent-Tears]

Tja, und da sind wir wieder bei Beta und dessen Auswirkungen, oder?

~amd64 ist beta.

 

[coolphoenix]

jo, deswegen hab ich ja meinen netten chroot

wobei ich mir nicht sicher bin, ob das wirklich an den ~amd64-packeten liegt oder am x86_64 (hatte mein x86_64 komplett neu aufgesetzt, ohne ~amd64, als ich andere probleme hatte - fehler blieben trotzdem... - egal, different story).

jedenfalls ist eine chroot-lösung "relativ" platzsparend (~1gb).

 

[Silent-Tears]

ubuntu 8.04 x86_64 lts läuft einwandfrei.

 

[pengu]

@schack
Genau das Problem hab ich auch, scheint aber nur bei der 7270 aufzutreten
(ist erst seit heute da, deshalb k.a. ob das mal ging).

In /usr/include/linux/limits.h ist PATH_MAX definiert.

Nun wollt ich nich extra ne virtuelle Maschine aufsetzen, auch wenn ich genug Platz hab.

Vielleicht noch wichtig: Gentoo läuft auf nem AMD 64 X2 (32 bit).

Sollte noch einer fragen wenn ich zuletzt ausgecheckt habe, das war vor ein paar Minuten.

Desweiteren hab ich, aufgrund einiger anfänglicher Probleme,
2 mal komplett neu angefangen (Toolchain, Rest).

 

[Silent-Tears]

@pengu Deine Informationen werden nciht ausreichen, dass dir da jemand hilft. Gut, fein. Du hast was ausgecheckt. Was?
Du hast eine 32bit-Version von Gentoo am Start, und einen amd64x2-Prozessor. Nichts ob stable oder unstable. Nichts von wegen trunk, stable branch oder was auch immer für eine Revision.
Und natürlich - stimmt - anscheinend baust du dir deine Toolchain selbst. Oder wieso fängst du da noch einmal an?

Als Tipp: Stable nutzen, Standards verwenden, richtige Fehlermeldungen posten, nachdem du überall stabile Versionen genutzt hast. Dann nämlich hat man eine Basis gefunden, mit der man arbeiten kann. Und vor allem sollte. Denn da du zumindest auf einem PC ~x86 als Arch in deiner make.conf stehen. Du weisst, dass es ebne genau in diesne unstable-Zweigen durchaus immer wieder zu Fehlern kommen kann, die du selber beheben können solltest und müsstest?

 

[pengu]

@pengu Deine Informationen werden nciht ausreichen, dass dir da jemand hilft. Gut, fein. Du hast was ausgecheckt. Was?

Seit Juli nutze ich Freetz und da ich gleich am Anfang Probleme mit der 1.0 hatte hol ich mir regelmäßig den neusten SVN (Revision 2593 im Moment).

Du hast eine 32bit-Version von Gentoo am Start, und einen amd64x2-Prozessor. Nichts ob stable oder unstable. Nichts von wegen trunk, stable branch oder was auch immer für eine Revision.

Gentoo 32bit unstable

Und natürlich - stimmt - anscheinend baust du dir deine Toolchain selbst. Oder wieso fängst du da noch einmal an?

Richtig erkannt, ich bau die Toolchain selbst.
Doch bekam ich auf einmal Probleme mit dem GCC (4.2.1),
sodass ich mich enschieden hab nochmal frisch auszuchecken
und auch die Toolchain neu zu bauen.

Als Tipp: Stable nutzen, Standards verwenden, richtige Fehlermeldungen posten, nachdem du überall stabile Versionen genutzt hast. Dann nämlich hat man eine Basis gefunden, mit der man arbeiten kann. Und vor allem sollte. Denn da du zumindest auf einem PC ~x86 als Arch in deiner make.conf stehen. Du weisst, dass es ebne genau in diesne unstable-Zweigen durchaus immer wieder zu Fehlern kommen kann, die du selber beheben können solltest und müsstest?

Richtig, dass es mal zu Fehlern kommen kann ist mir bekannt,
bisher immer eine Lösung gefunden.

Ich war nun der Meinung was für die 7170 geht geht auch für die 7270.

Meine Aussage weiter oben stimmt nicht ganz.
Vor ein paar Tagen hab ich (mal testweise)
ein Image für die 7270 gebaut und da ist genau das, um was es hier geht nicht aufgetreten.

Ach sorry bevor ich es vergesse:

Natürlich kann ich hier nochmal zu besten geben was hier genau schieflief,
doch das ist bereits im ersten Post passiert.

Doch wenn es hilft ..

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  HOSTCC  scripts/mod/sumversion.o
scripts/mod/sumversion.c: In Funktion »get_src_version«:
scripts/mod/sumversion.c:384: Fehler: »PATH_MAX« nicht deklariert (erste Benutzung in dieser Funktion)
scripts/mod/sumversion.c:384: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt
scripts/mod/sumversion.c:384: Fehler: für jede Funktion in der er auftritt.)
scripts/mod/sumversion.c:384: Warnung: Variable »filelist« wird nicht verwendet
make[3]: *** [scripts/mod/sumversion.o] Fehler 1
make[2]: *** [scripts/mod] Fehler 2
make[1]: *** [scripts] Fehler 2

Update

nach Änderung besagter sumversion.c geht es nun.
Aus den vorherigen Posts geht schon alles nötige hervor.
So hab ich nun eins und eins zusammengezählt
und entdeckt dass besagter Header nirgends eingebunden ist.
Besagten Header eingebunden und es geht.

 

[Miyamoto]

Update

nach Änderung besagter sumversion.c geht es nun.
Aus den vorherigen Posts geht schon alles nötige hervor.
So hab ich nun eins und eins zusammengezählt
und entdeckt dass besagter Header nirgends eingebunden ist.
Besagten Header eingebunden und es geht.

Wie konkret bindest du den Header ein?

 

[olistudent]

http://www.freetz.org/changeset/2661

MfG Oliver