Kernel-Kompilierung / parse-errors in serial.c
Hi, so langsam komme ich mir doch wirklich blöd vor. Wieso kann ich denn den 2.4.18er Kernel jetzt überhaupt nicht mehr kompilieren? Bei der serial.c bekomme ich eine Menge parse-Errors und das war's. Ende. Ich peil' das nit ;-( Das ist jetzt schon der 6. Versuch, das Ding zu kompilieren, ich habe auch schon ma gegoogled und habe parse errors nur in Bezug auf einen 18-pre gefunden und meist nur in französisch ;-( Hat jemand irgendeine Idee? Ich habe dem Makefile eine Extraversion beigegeben, die da lautet "STB.net-1.8", natürlich ohne die "". Also da bestimmt wieder Nachfragen kommen, was ich denn für parse-errors bekomme hier gleich mal ein frischer copy-paste... ;-) ================================================== gcc -D__KERNEL__ -I/admin/kernel-2.4.18/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586 -DKBUILD_BASENAME=selection -DEXPORT_SYMTAB -c selection.c gcc -D__KERNEL__ -I/admin/kernel-2.4.18/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i586 -DKBUILD_BASENAME=serial -DEXPORT_SYMTAB -c serial.c In file included from serial.c:181: /admin/kernel-2.4.18/include/linux/serialP.h:27: parse error serial.c:201: parse error serial.c:204: parse error serial.c:225: parse error serial.c:677: parse error serial.c:1432: parse error serial.c:1581: parse error serial.c:2157: parse error serial.c:2204: parse error serial.c:2381: parse error serial.c:2538: parse error serial.c:2553: parse error serial.c:3167: parse error serial.c:3831: parse error serial.c:3836: linux/symtab_begin.h: No such file or directory serial.c:3839: linux/symtab_end.h: No such file or directory serial.c:5386: parse error serial.c:5389: parse error serial.c:5424: parse error serial.c:5427: parse error serial.c:5438: parse error serial.c:5445: parse error serial.c: In function `receive_chars': serial.c:680: warning: implicit declaration of function `queue_task_irq_off' serial.c: In function `rs_write': serial.c:1876: warning: implicit declaration of function `copy_from_user' serial.c: In function `get_serial_info': serial.c:2074: warning: implicit declaration of function `copy_to_user' serial.c: At top level: serial.c:3835: variable `serial_syms' has initializer but incomplete type serial.c:3837: warning: implicit declaration of function `X' serial.c:3837: warning: excess elements in struct initializer serial.c:3837: warning: (near initialization for `serial_syms') serial.c:3838: warning: excess elements in struct initializer serial.c:3838: warning: (near initialization for `serial_syms') serial.c:2398: warning: `rs_break' defined but not used serial.c:3835: warning: `serial_syms' defined but not used make[3]: *** [serial.o] Error 1 make[3]: Leaving directory `/admin/kernel-2.4.18/drivers/char' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/admin/kernel-2.4.18/drivers/char' make[1]: *** [_subdir_char] Error 2 make[1]: Leaving directory `/admin/kernel-2.4.18/drivers' make: *** [_dir_drivers] Error 2 server:/admin/kernel-2.4.18 # ================================================== Soviel dann dazu. Danke Euch schon mal, Michael
* Freitag, 29. März 2002 um 16:42 (+0100) schrieb Michael Jakscht:
so langsam komme ich mir doch wirklich blöd vor. Wieso kann ich denn den 2.4.18er Kernel jetzt überhaupt nicht mehr kompilieren? Bei der serial.c bekomme ich eine Menge parse-Errors und das war's. Ende. [...] Hat jemand irgendeine Idee? Ich habe dem Makefile eine Extraversion beigegeben, die da lautet "STB.net-1.8", natürlich ohne die "".
Also da bestimmt wieder Nachfragen kommen, was ich denn für parse-errors bekomme hier gleich mal ein frischer copy-paste... ;-)
Und das hilft auch weiter...
/admin/kernel-2.4.18/include/linux/serialP.h:27: parse error serial.c:201: parse error serial.c:204: parse error serial.c:225: parse error serial.c:677: parse error [...]
In all den Zeilen wird eine Pre-Processor-Variable "LINUX_VERSION_CODE" mit einem numerischen Wert verglichen. Vermutlich klappt das aus irgendeinem Grunde nicht... Ich habe da deine Extraversion in Verdacht. Aber ich kann nicht erkennen, wie oder warum, denn "eigentlich" wird in "linux/Makefile" "LINUX_VERSION_CODE" lediglich aus "VERSION", "PATCHLEVEL" und "SUBLEVEL" berechnet, also ohne "EXTRAVERSION". Mehr kann ich dazu allerdings auch nicht sagen. BTW: Weiß jemand, wo/wie nach einem '@mv -f .ver $@' in einem Makefile (linux/Makefile) die Datei ".ver" ist/heisst? Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Am Fre, 2002-03-29 um 23.07 schrieb Andreas Koenecke:
BTW: Weiß jemand, wo/wie nach einem '@mv -f .ver $@' in einem Makefile (linux/Makefile) die Datei ".ver" ist/heisst?
So wie die linke Seite der zugehörigen Regel, in dessen Produktionteil diese Zeile steht :) Wenn Du z.B. diese Regel des Kernel-Toplevel-Makefiles meinst : include/linux/version.h: ./Makefile ./.kversion [..] @mv -f .ver $@ => include/linux/version.h Siehe info make Ralf
* Samstag, 30. März 2002 um 06:28 (+0100) schrieb Ralf Corsepius:
Wenn Du z.B. diese Regel des Kernel-Toplevel-Makefiles meinst :
include/linux/version.h: ./Makefile ./.kversion [..] @mv -f .ver $@
=> include/linux/version.h
Ja, das meinte ich. Danke. Michael: Kannst du die "linux/include/linux/version.h" mailen, falls du die Kernel-Version mit dem Parse-Error noch hast. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hi Andreas, danke für Deine Mühe erst mal, Andreas Koenecke [mailto:akoenecke@akoenecke.de] schrieb am Samstag, 30. März 2002 10:33:
Michael: Kannst du die "linux/include/linux/version.h" mailen, falls du die Kernel-Version mit dem Parse-Error noch hast.
Nein, die hatte ich etwas gefrustet gelöscht, ich lade mir aber gerade nochmal den 18er als tar.gz, das sollte dann ja exakt die gleiche Version sein, bei der es nicht ging (ich habe ebenfalls mit der tar.gz Probleme gehabt). So, nun habe ich wie gesagt den 17er als tar.bz2 geladen, entpackt, mit den gleichen Einstellungen kompiliert, eine initial ramdisk mit reiserfs, 3c509 und 8139too erstellt, lilo ausgeführt und gebootet, siehe da, es läuft wunderbar. Naja wie gesagt jetzt werde ich auf dem laufenden 17er den 18er kompilieren und mal schauen was dabei herauskommt. Währenddessen suche ich die version.h raus und maile sie hier. Michael
Hi, Michael Jakscht [mailto:michael@jakscht.de] schrieb am Samstag, 30. März 2002 11:25:
Währenddessen suche ich die version.h raus und maile sie hier.
so, ich habe gesucht wie ein wilder, aber sorry, so eine Datei gibt es in der tar.gz Version gar nicht. Kann das sein? Ich habe in include/linux danach geschaut, aber da ist sie echt nicht ;-// Dann habe ich mit find versucht was zu suchen, weiss aber nicht, wie ich rekursiv durch die Verzeichne suchen kann. In der manpage von find habe ich nach recursive gesucht aber auch nichts gefunden. Entpacke gerade das 18er tar.bz2 Archiv. Vielleicht gibt's dort die version.h. Mal sehen... Nein, da gibt es sie auch nicht. Liegt die irgendwo anders, oder ist die Datei erst nach irgendwelchem make's da? Michael
Am Sam, 2002-03-30 um 12.00 schrieb Michael Jakscht:
Hi,
Michael Jakscht [mailto:michael@jakscht.de] schrieb am Samstag, 30. März 2002 11:25:
Währenddessen suche ich die version.h raus und maile sie hier.
so, ich habe gesucht wie ein wilder, aber sorry, so eine Datei gibt es in der tar.gz Version gar nicht. Kann das sein?
Ja, da sie während der Kernelkonfiguration genau vom vorhin angesprochenen Teil des Makefiles generiert wird Ralf
Hi, ich habe inzwischen einiges in Erfahrung bringen können. Also, der 2.4.17er läuft wie geschmiert, den 2.4.18er kriege ich nicht zum laufen. Egal, was ich mache und wie ich es mache, es geht nicht. Ich habe laut David's Multikernel-Seite auch die System.map's entsprechend benannt, er fand schliesslich auch die richtige, aber trotzdem konnten irgendwelche mii_*-Abhängigkeiten nicht aufgelöst werden. Nun gut, nun läuft also der 17er und das war's dann für mich. Den 18er kann ich also nicht gebrauchen, läuft schlicht und ergreifend einfach *nicht*. BTW, ich habe für meine Kernel die gleiche Konfigurationsdatei gehabt. Neu bei 18er war eine Option für die schnellere RX Erkennung oder sowas bei der RTL8139-Karte. Ich hab's mit und ohne probiert. Den Support für die älteren Karten benötige ich sowieso beim RTL8139-Modul. Eine Idee kommt mir gerade noch, was (oder überhaupt) hat es für Auswirkungen, wenn man den Kartentreiber erst als Modul kompiliert, die Module installiert und dann Kernel neu erstellt, allerdings mit dem Kartentreiber nicht als Modul sondern einkompiliert, sodass dann beides zur Verfügung steht? (Also einmal einkompiliert und einmal in /lib/modules/...) Aber ich denke dadurch würde ich meine Chancen nicht erhöhen, dass es läuft. Grüsse, Michael
Hallo Michael, * Samstag, 30. März 2002 um 16:55 (+0100) schrieb Michael Jakscht:
ich habe inzwischen einiges in Erfahrung bringen können. Also, der 2.4.17er läuft wie geschmiert, den 2.4.18er kriege ich nicht zum laufen. [ ... ] Ich habe laut David's Multikernel-Seite auch die System.map's entsprechend benannt, er fand schliesslich auch die richtige, aber trotzdem konnten irgendwelche mii_*-Abhängigkeiten nicht aufgelöst werden. Nun gut, nun läuft also der 17er und das war's dann für mich. Den 18er kann ich also nicht gebrauchen, läuft schlicht und ergreifend einfach *nicht*.
Im 2.4.18 sind (vermutlich allgemeine) Teile des Netzwerkkarten-Codes in ein separates Modul "mii.o" ausgelagert worden. Diese Modul wird i.A. automatisch erzeugt und geladen. So auch hier bei mir , aber anscheinend nicht bei dir... In einer anderen Mail in diesem Thread schriebst du, das du die Netzwerkmodule in die Initial-Ramdisk legst -- Warum? Ich glaube, da liegt das Problem: Falls du wirklich die Netzwerk-Module in der Initial-Ramdisk brauchst (normalerweise nicht!), dann musst du das Modul "mii.o" auch hinzufügen.
Eine Idee kommt mir gerade noch, was (oder überhaupt) hat es für Auswirkungen, wenn man den Kartentreiber erst als Modul kompiliert, die Module installiert und dann Kernel neu erstellt, allerdings mit dem Kartentreiber nicht als Modul sondern einkompiliert, sodass dann beides zur Verfügung steht? (Also einmal einkompiliert und einmal in /lib/modules/...)
IMHO werden dann die Module einfach nicht geladen, weil deren Funktion schon "fest" im Kernel ist. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hi Andreas, Andreas Koenecke [mailto:akoenecke@akoenecke.de] schrieb am Samstag, 30. März 2002 17:54:
In einer anderen Mail in diesem Thread schriebst du, das du die Netzwerkmodule in die Initial-Ramdisk legst -- Warum?
Huh, Du fragst Sachen ;-)), Ich mache das, weil eine Standard-Installation von SuSE halt eben genau meine drei benötigten Module in eine Initial Ramdisk legt. (reiserfs, 3c509 + rtl8139) So. Daran habe ich mich gehalten und AFAIK hatte ich auch bei meinen ersten Kernel-Geh-Versuchen Probleme, weil ich genau den Schritt nicht gemacht hatte. (initrd anlegen) Von daher habe ich auch so weiter gemacht, die Module halt in eine initrd zu packen.
Ich glaube, da liegt das Problem: Falls du wirklich die Netzwerk-Module in der Initial-Ramdisk brauchst (normalerweise nicht!), dann musst du das Modul "mii.o" auch hinzufügen.
Na, dann werde ich ich wohl noch einen Versuch starten. Es juckt mir ja schon wieder unter Fingern ;-)) Gruss, Michael
Hi Andreas, Andreas Koenecke [mailto:akoenecke@akoenecke.de] schrieb am Samstag, 30. März 2002 17:54:
Ich glaube, da liegt das Problem: Falls du wirklich die Netzwerk-Module in der Initial-Ramdisk brauchst (normalerweise nicht!), dann musst du das Modul "mii.o" auch hinzufügen.
So, habe es eben nochmal probiert. Die Reihenfolge in der rc.config sieht nun wie folgt aus "reiserfs mii 8139too 3c905". Bestens! Es läuft prima. Nun habe ich glücklicherweise *wischdenschweissvonderstirnab* einen 2.4.18er Kernel. Danke für Eure Hilfe! Jetzt wo ich weiss, wonach ich suchen muss, habe ich mal eben in den ChangeLog geschaut. Gut, da steht zwar an 3 od. 4 Stellen was von mii, aber auch dadurch wäre ich nicht darauf gekommen, dass dieses Modul nun auch noch mit in die Initial Ramdisk muss... :-/ Grüsse, Michael
Hi Andreas, Andreas Koenecke [mailto:akoenecke@akoenecke.de] schrieb am Freitag, 29. März 2002 23:07:
Also da bestimmt wieder Nachfragen kommen, was ich denn für parse-errors bekomme hier gleich mal ein frischer copy-paste... ;-) Und das hilft auch weiter...
Hihi, gut, ne'? Ich lerne dazu... ;-))
Ich habe da deine Extraversion in Verdacht.
Also ich habe die auch schon mal wieder rausgenommen, vorher natürlich einen make mrproper gemacht und dann noch mal probiert, gleiches Problem. Ich wills jetzt mal mit dem 17er versuchen. Mal schau'n, vielleicht geht's. Wenn das geht, schalte ich meinen Squid mal aus, sauge mir ein fünftes Mal den vollen 18er und lade ihn noch mal auf den Server und probiere es dann nochmal mit dem 18er. Mal schauen... :-) Michael
participants (3)
-
Andreas Koenecke -
Michael Jakscht -
Ralf Corsepius