wo liegen Kernel-Header, warum "unresolved symbols"
Hallo Listenbrüder und -Schwester :) Ich hänge immer noch an meinem Problem, mir die CAPI für eine Fritz PCI passend zu einem Updatekernel (2.4.17) zu backen (hatte dazu unter "Modprobe, Treiber, neue Kernel" schon mal um Hilfe gerufen). Gcc compiliert sauber durch, aber das generierte Modul enthält "unresolved symbols". Ein depmod -e wirft mir eine Latte an nicht auflösbaren Funktionen aus, darunter kmalloc - das ist doch eine stinknormale Kernelfunktion zum Reservieren von Speicher, oder? (komplette Liste hänge ich unten an) Also scheine ich gegen irgendeinen Kernel zu compilieren, nur nicht gegen den installierten. Der /usr/src/linux zeigt aber auf das richtige Verzeichnis, also muss es doch sonstwo noch Verweise auf den aktuellen Kernel geben. Wo liegen denn normalerweise die Kernel-Header noch? Irgendwo, nehme ich an, sollte es irgendwelche wichtigen Dateien in einem Include-Verzeichnis geben, die auf meinem System fehlen (also die der Kernel-Update per SuSE-RPM nicht richtig installiert hat). Allerdings hat das System, denn vorher hatte ich 2.4.16 per RPM installiert, und da hatte ich das gleiche Problem. Any hints? Äh, und weiß jemand, was der depmod-Kommentar "depmod: cannot read ELF header from /lib/modules/2.4.17-4GB/modules.pnpbiosmap" bedeutet und wie ich das korrigieren kann? Dank und Gruß, Alfred --- Ausgabe von depmod -e --- depmod: *** Unresolved symbols in /lib/modules/2.4.17-4GB/kernel/drivers/isdn/fritz/fcpci.o depmod: enable_irq depmod: __kfree_skb depmod: alloc_skb depmod: __release_region depmod: tq_immediate depmod: attach_capi_driver depmod: kmalloc depmod: _ctype depmod: pci_enable_device depmod: __check_region depmod: vfree depmod: detach_capi_driver depmod: boot_cpu_data depmod: cpu_raise_softirq depmod: pcibios_present depmod: free_irq depmod: bh_task_vec depmod: kfree depmod: disable_irq depmod: request_irq depmod: skb_over_panic depmod: pci_find_device depmod: __tasklet_hi_schedule depmod: jiffies depmod: __vmalloc depmod: softnet_data depmod: __request_region depmod: printk depmod: irq_stat depmod: ioport_resource -----
Hallo, On Mon, 18 Mar 2002, Alfred Poschmann wrote:
Ich hänge immer noch an meinem Problem, mir die CAPI für eine Fritz PCI passend zu einem Updatekernel (2.4.17) zu backen (hatte dazu unter "Modprobe, Treiber, neue Kernel" schon mal um Hilfe gerufen). Gcc compiliert sauber durch, aber das generierte Modul enthält "unresolved symbols".
Hatte ich gelesen, aber von ISDN etc. pp. hab ich null Ahnung ;0
Ein depmod -e wirft mir eine Latte an nicht auflösbaren Funktionen aus, darunter kmalloc - das ist doch eine stinknormale Kernelfunktion zum Reservieren von Speicher, oder? (komplette Liste hänge ich unten an)
Apropos: Sind deine modutils aktuell genug??? Das koennte u.U. die Ursache sein. Ansonsten... Hm... Mail mir mal per PM deine .config...
Also scheine ich gegen irgendeinen Kernel zu compilieren, nur nicht gegen den installierten. Der /usr/src/linux zeigt aber auf das richtige Verzeichnis, also muss es doch sonstwo noch Verweise auf den aktuellen Kernel geben.
/usr/include/linux und /usr/include/asm sind symlinks auf die Kernelheader- verz. (via /usr/src/linux) oder aber auch gegen die Header, gegen die die libc kompiliert wurde. Beides ist (in Grenzen) sinnvoll bzw. schaedlich.
Any hints?
Äh, und weiß jemand, was der depmod-Kommentar "depmod: cannot read ELF header from /lib/modules/2.4.17-4GB/modules.pnpbiosmap" bedeutet und wie ich das korrigieren kann?
Das deutet IMO auch auf die modutils hin. AFAIK wurde diese Datei mit 2.4 (in den stable Kernel) eingefuehrt, und dein depmod scheint die aber wie ein Module (*.o) lesen zu wollen.
depmod: *** Unresolved symbols in /lib/modules/2.4.17-4GB/kernel/drivers/isdn/fritz/fcpci.o [1,2,viele ;0]
s.o. -dnh -- I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. -- Albert Einstein
Irgendwas stimmt mit der Liste nicht. Ich empfange meine eigenen Postings nichts, es kommen aber Antworten, also bekommt Ihr sie schon ... gomisch. Am Die, 2002-03-19 um 07.58 schrieb David Haller:
Ein depmod -e wirft mir eine Latte an nicht auflösbaren Funktionen aus, darunter kmalloc - das ist doch eine stinknormale Kernelfunktion zum Reservieren von Speicher, oder? (komplette Liste hänge ich unten an)
Apropos: Sind deine modutils aktuell genug??? Das koennte u.U. die Ursache sein. Ansonsten... Hm... Mail mir mal per PM deine .config...
Ein rpm -q modutils brachte modutils-2.4.5-12. Die muss ich doch nicht fuer jeden Minor-Upgrade ebenfalls aufrüsten, oder? Anyway, das aktuellste, was ich bei suse.com finden konnte, war modutils-2.4.12-11.rpm. Werde ich gleich mal installieren.
Also scheine ich gegen irgendeinen Kernel zu compilieren, nur nicht gegen den installierten. Der /usr/src/linux zeigt aber auf das richtige Verzeichnis, also muss es doch sonstwo noch Verweise auf den aktuellen Kernel geben.
/usr/include/linux und /usr/include/asm sind symlinks auf die Kernelheader- verz. (via /usr/src/linux) oder aber auch gegen die Header, gegen die die libc kompiliert wurde. Beides ist (in Grenzen) sinnvoll bzw. schaedlich.
Ich erinnere mich an die Debatte :) /usr/include/linux ist ein "echtes" Verzeichnis (das btw eine Datei dn.h enthält, *g*). Darin ist ein Link auf version.h der Kernel-Sourcen - aber den habe wahrscheinlich ich selbst angelegt (wenn ich nur noch wüsste, was ich alles gemacht habe). Ansonsten liegen da Header zu allen möglichen Programmen, teilweise von 1997 - weiß daher nicht, ob ich dieses Verzeichnis umbenennen und durch einen Link ersetzen soll. In /usr/src/linux finden sich die gleichen Dateien (gleicher Name), sie sind aber offensichtlich neuer und enthalten andere Daten. Gleiches gilt auch für /usr/include/asm. Würdet Ihr raten, die Verzeichnisse durch einen Link zu ersetzen oder muss ich dann in ein paar Wochen, wenn ich mich hieran nicht mehr erinnere (s.o., mein zweiter Vorname ist Vergesslichkeit) mit Problemen rechnen?
Any hints?
Äh, und weiß jemand, was der depmod-Kommentar "depmod: cannot read ELF header from /lib/modules/2.4.17-4GB/modules.pnpbiosmap" bedeutet und wie ich das korrigieren kann?
Das deutet IMO auch auf die modutils hin. AFAIK wurde diese Datei mit 2.4 (in den stable Kernel) eingefuehrt, und dein depmod scheint die aber wie ein Module (*.o) lesen zu wollen.
Werde ich gleich testen. Danke schon mal - endlich wieder eine sinnvolle Spur! Grüße, Alfred
Alfred Poschmann
/usr/include/linux und /usr/include/asm sind symlinks auf die Kernelheader- verz. (via /usr/src/linux) oder aber auch gegen die Header, gegen die die libc kompiliert wurde. Beides ist (in Grenzen) sinnvoll bzw. schaedlich.
Ich erinnere mich an die Debatte :) /usr/include/linux ist ein "echtes" Verzeichnis (das btw eine Datei dn.h enthält, *g*). Darin ist ein Link auf version.h der Kernel-Sourcen - aber den habe wahrscheinlich ich selbst angelegt (wenn ich nur noch wüsste, was ich alles gemacht habe). Ansonsten liegen da Header zu allen möglichen Programmen, teilweise von 1997 - weiß daher nicht, ob ich dieses Verzeichnis umbenennen und durch einen Link ersetzen soll. In /usr/src/linux finden sich die gleichen Dateien (gleicher Name), sie sind aber offensichtlich neuer und enthalten andere Daten. Gleiches gilt auch für /usr/include/asm.
Würdet Ihr raten, die Verzeichnisse durch einen Link zu ersetzen oder muss ich dann in ein paar Wochen, wenn ich mich hieran nicht mehr erinnere (s.o., mein zweiter Vorname ist Vergesslichkeit) mit Problemen rechnen?
:~> rpm -qf /usr/include/linux glibc-devel-2.2.4-64 :~> rpm -qf /usr/include/asm glibc-devel-2.2.4-64 -- In the begining was the word, and the word was: Content-Type: text/plain; charset=us-ascii
Hallo, On Tue, 19 Mar 2002, Martin Schmitz wrote:
Alfred Poschmann
writes: :~> rpm -qf /usr/include/linux glibc-devel-2.2.4-64 :~> rpm -qf /usr/include/asm glibc-devel-2.2.4-64
Jo. Die Frage ist nur, ob da bei Alfred nicht noch mehr drin ist, daher der Vorschlag mit dem 'rpm -qf /usr/include/linux/* | sort -u'. $ rpm -qf /usr/include/asm /usr/include/linux libc-2.1.3-65 libc-2.1.3-65 alsa-devel-0.5.10-89 $ rpm -qlv libc | grep '/usr/include/\(asm\|linux\)' lrwxrwxrwx [..] /usr/include/asm -> ../src/linux/include/asm-i386 lrwxrwxrwx [..] /usr/include/linux -> ../src/linux/include/linux Aha... *lol* (erstere beiden sind sogar "korrekt" fuer _meine_ SuSE- Version, aber ISTR, dass SuSE da inzwischen auf Linus' Variante umgestiegen ist, d.h. /usr/src/{linux,asm} sind echte Verzeichnisse, die die kernel-header des kernels enthalten, gegen den die libc kompiliert wurde[1]. Das: $ rpm -qlv alsa-devel drwxr-xr-x [..] /usr/include/linux ist allerdings flasch (Fehler im spec des RPM, aber die Alsa Version is ja "alt)[2]. Tja, und ich _vermute_, bei Alfred ist was in dieser Richtung daneben gegangen... -dnh [1] Ob/warum/warum nicht wurde ausfuehrlich diskutiert... [2] Hm. Note to self: Wieso hab ich Alsa eigentlich installiert, wenn ich's nicht verwende? *g* -- Networks are like sewers ... My job is to make sure your data goes away when you flush, and to stop the rats climbing into your toilet through the pipes. (Tanuki, describing network administration.)
Am Mit, 2002-03-20 um 03.46 schrieb der hellsehende David Haller:
Hallo,
On Tue, 19 Mar 2002, Martin Schmitz wrote:
Alfred Poschmann
writes: [..]
$ rpm -qf /usr/include/asm /usr/include/linux libc-2.1.3-65 libc-2.1.3-65 alsa-devel-0.5.10-89
$ rpm -qlv libc | grep '/usr/include/\(asm\|linux\)' lrwxrwxrwx [..] /usr/include/asm -> ../src/linux/include/asm-i386 lrwxrwxrwx [..] /usr/include/linux -> ../src/linux/include/linux
Aha... *lol* (erstere beiden sind sogar "korrekt" fuer _meine_ SuSE- Version, aber ISTR, dass SuSE da inzwischen auf Linus' Variante umgestiegen ist, d.h. /usr/src/{linux,asm} sind echte Verzeichnisse, die die kernel-header des kernels enthalten, gegen den die libc kompiliert wurde[1].
Das: $ rpm -qlv alsa-devel drwxr-xr-x [..] /usr/include/linux
ist allerdings flasch (Fehler im spec des RPM, aber die Alsa Version is ja "alt)[2]. Tja, und ich _vermute_, bei Alfred ist was in dieser Richtung daneben gegangen...
Gut vermutet! # rpm -qf /usr/include/linux/* | sort -u die Datei »/usr/include/linux/modversions.h« gehört zu keinem Paket alsa-devel-0.5.11-74 glibc-devel-2.2.2-6 modversion liegt wohl da, weil ich in meiner Verzweiflung mittlerweile die Module aus den Sourcen neu compiliert habe. Aber tatsächlich: Alsa! Nur, wie kann ich das korrigieren, ohne meinen Sound zu verlieren? Meine Töchter würden leiden, wenn sie ihre Kleinkinderlieder nicht mehr im Keller hören könnten (oder genauer, ich würde leiden, weil das Geschreppe dann hier bei mir läuft :) Ich werde also mal die kompletten Verzeichnisse nach /usr/src/linux/... linken und mal sehen, was abgeht. Die Welt ist einfach (/) komplexer, als man glaubt. Alfred
Hallo, On Wed, 20 Mar 2002, Alfred Poschmann wrote:
Am Mit, 2002-03-20 um 03.46 schrieb der hellsehende David Haller:
On Tue, 19 Mar 2002, Martin Schmitz wrote:
Alfred Poschmann
writes: [..] # rpm -qf /usr/include/linux/* | sort -u die Datei »/usr/include/linux/modversions.h« gehört zu keinem Paket alsa-devel-0.5.11-74 glibc-devel-2.2.2-6 modversion liegt wohl da, weil ich in meiner Verzweiflung mittlerweile die Module aus den Sourcen neu compiliert habe. Aber tatsächlich: Alsa!
Nur, wie kann ich das korrigieren, ohne meinen Sound zu verlieren? Meine Töchter würden leiden, wenn sie ihre Kleinkinderlieder nicht mehr im Keller hören könnten (oder genauer, ich würde leiden, weil das Geschreppe dann hier bei mir läuft :)
Du muesstest Alsa wohl eben wie die anderen Kernelmodule neu kompilieren, wie das geht weiss ich aber nicht, da ich alsa nicht kenne... Generell geht das aber genauso, wie beim ersten Mal.
Ich werde also mal die kompletten Verzeichnisse nach /usr/src/linux/... linken und mal sehen, was abgeht.
Viel Glueck ;) -dnh -- Och yes. I used to have a brain once. If anyone sees it, please ask it to come back, I miss it sometimes. -- Frossie in the SDM
Hallo, On Tue, 19 Mar 2002, Alfred Poschmann wrote:
Irgendwas stimmt mit der Liste nicht. Ich empfange meine eigenen Postings nichts, es kommen aber Antworten, also bekommt Ihr sie schon ... gomisch.
Vielleicht ist die nur irgendwo (vorruebergehend) haengengeblieben (z.B. in irgendnem Virusscanner) und kommt spaeter..
Am Die, 2002-03-19 um 07.58 schrieb David Haller:
Ein depmod -e wirft mir eine Latte an nicht auflösbaren Funktionen aus, darunter kmalloc - das ist doch eine stinknormale Kernelfunktion zum Reservieren von Speicher, oder? (komplette Liste hänge ich unten an)
Apropos: Sind deine modutils aktuell genug??? Das koennte u.U. die Ursache sein. Ansonsten... Hm... Mail mir mal per PM deine .config...
Ein rpm -q modutils brachte modutils-2.4.5-12. Die muss ich doch nicht fuer jeden Minor-Upgrade ebenfalls aufrüsten, oder? Anyway, das aktuellste, was ich bei suse.com finden konnte, war modutils-2.4.12-11.rpm. Werde ich gleich mal installieren.
Und was steht bei 2.4.17 in der Documentation/Changes? Fuer 2.4.16 ist modutils-2.4.2 aktuell genug... Ich wuerde also eigentlich tippen, dass das aktuell genug waere... Mach evtl. mal ein 'rpm --verify modutils' und/oder ein 'rpm -qf `which depmod`'...
Also scheine ich gegen irgendeinen Kernel zu compilieren, nur nicht gegen den installierten. Der /usr/src/linux zeigt aber auf das richtige Verzeichnis, also muss es doch sonstwo noch Verweise auf den aktuellen Kernel geben.
/usr/include/linux und /usr/include/asm sind symlinks auf die Kernelheader- verz. (via /usr/src/linux) oder aber auch gegen die Header, gegen die die libc kompiliert wurde. Beides ist (in Grenzen) sinnvoll bzw. schaedlich.
Ich erinnere mich an die Debatte :) /usr/include/linux ist ein "echtes" Verzeichnis (das btw eine Datei dn.h enthält, *g*).
*g*
Darin ist ein Link auf version.h der Kernel-Sourcen - aber den habe wahrscheinlich ich selbst angelegt (wenn ich nur noch wüsste, was ich alles gemacht habe). Ansonsten liegen da Header zu allen möglichen Programmen, teilweise von 1997 - weiß daher nicht, ob ich dieses Verzeichnis umbenennen und durch einen Link ersetzen soll. [..] Würdet Ihr raten, die Verzeichnisse durch einen Link zu ersetzen oder muss ich dann in ein paar Wochen, wenn ich mich hieran nicht mehr erinnere (s.o., mein zweiter Vorname ist Vergesslichkeit) mit Problemen rechnen?
Waere auf jeden Fall mal einen Versuch wert... Wie gesagt, beides geht solange das Kernel-Api abwaertskompatibel ist. Interessant dazu waere evtl. auch, was ein 'rpm -qf /usr/include/linux/* | sort -u' ausspuckt, also woher diese Dateien ueberhaupt stammen. Falls da irgendwas durch- einander ist, ist das ersetzen (umbennenen des jetzigen) durch einen symlink wohl das einfachste (musst nur die Daumen druecken, dass dann noch alles was gegen das (evtl.) Chaos da mal kompiliert wuerde)... Achso: fuer /usr/include/asm gilt das gleiche. Die zu setzenden symlinks waeren: ln -s ../../src/linux/include/asm /usr/include/asm ln -s ../../src/linux/include/linux /usr/include/linux Du kannst die ja erstmal probehalber setzen und schauen, ob das Problem dadurch verschwindet. Wenn nicht kannst du ja direkt wieder den jetzigen Zustand wiederherstellen.
Danke schon mal - endlich wieder eine sinnvolle Spur!
*g* -dnh -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson
Am Die, 2002-03-19 um 21.43 schrieb David Haller:
Und was steht bei 2.4.17 in der Documentation/Changes? Fuer 2.4.16 ist modutils-2.4.2 aktuell genug... Ich wuerde also eigentlich tippen, dass das aktuell genug waere... Mach evtl. mal ein 'rpm --verify modutils' und/oder ein 'rpm -qf `which depmod`'...
Die neuen modutils haben den Ausgabefehler korrigiert. Und ich dachte, die blieben für den kompletten Kernel 2.4 gleich ... [..]
Würdet Ihr raten, die Verzeichnisse durch einen Link zu ersetzen oder muss ich dann in ein paar Wochen, wenn ich mich hieran nicht mehr erinnere (s.o., mein zweiter Vorname ist Vergesslichkeit) mit Problemen rechnen?
[..]
ln -s ../../src/linux/include/asm /usr/include/asm ln -s ../../src/linux/include/linux /usr/include/linux
Du kannst die ja erstmal probehalber setzen und schauen, ob das Problem dadurch verschwindet. Wenn nicht kannst du ja direkt wieder den jetzigen Zustand wiederherstellen.
Hab's ausprobiert, aber keine Änderung :( Statt dessen hat das Installscript von thepenguin.de einen selbstrefenrenzierten Link auf /usr/src/.../version.h gelegt (weil es in /usr/include/linux einen link auf die version.h in den Sourcen legt), so dass ich es modifizieren musste. Aber alles hat nicht geholfen, so dass ich mich jetzt wohl der Hoffnungslosigkeit anheim gebe. Das AVM-Modul selbst hat übrigens kein makefile und kein .config. In den einzelnen Programmteilen taucht der verräterische String "kernel_2.4.10" (ich habe ja 2.4.17 installiert) übrigens nicht auf, erst im komplett gelinkten Modul. Kann es sein, dass beim Linken etwas schiefgeht? Und wieso? Ist Linken mehr als ein cat der einzelnen Teile? Wie kann man so etwas nachvollziehen? Manchmal wünschte ich mir wirklich, ich verstünde etwas mehr vom Programmieren. Was das jetzt schon an Zeit gefressen hat - meine und Eure ... Sigh, Alfred
Hallo, On Thu, 21 Mar 2002, Alfred Poschmann wrote:
Am Die, 2002-03-19 um 21.43 schrieb David Haller: [..]
ln -s ../../src/linux/include/asm /usr/include/asm ln -s ../../src/linux/include/linux /usr/include/linux
Du kannst die ja erstmal probehalber setzen und schauen, ob das Problem dadurch verschwindet. Wenn nicht kannst du ja direkt wieder den jetzigen Zustand wiederherstellen.
Hab's ausprobiert, aber keine Änderung :(
Hm. Zwischendurch den Kerneltree gesaeubert? Leider kenn ich mich mit ISDN wie gesagt gar nicht aus... Kannst mir aber mal die URL von dem Dingens mailen... [..]
Das AVM-Modul selbst hat übrigens kein makefile und kein .config.
Das bedeutet AFAIK, dass das "im Kernel" zu kompilieren waere, aber ich schau mir das dann evtl. lieber erstmal an...
In den einzelnen Programmteilen taucht der verräterische String "kernel_2.4.10" (ich habe ja 2.4.17 installiert)
SuSE oder Vanilla?
übrigens nicht auf, erst im komplett gelinkten Modul. Kann es sein, dass beim Linken etwas schiefgeht?
Ja. Leider kann ich ohne weitere Infos (v.a. ueber den Treiber) nix weiters sagen...
Ist Linken mehr als ein cat der einzelnen Teile?
Ja. Da wird u.a. ggfs. startcode, initcode usw. dazugebastelt sowie ggfs. die Symbole versioniert...
Wie kann man so etwas nachvollziehen?
Evtl. mit 'make CC="gcc -v"'. Solltest du aber nicht auf den ganzen Kernel ansetzen, das wuerde dich wohl ein wenig arg zubretzeln (ein log duerfte ca. 3-4 mal so gross werden ;)... Besser setz es auf ne einzelne Datei an, z.B. auf ein "hello-World" ;)
Manchmal wünschte ich mir wirklich, ich verstünde etwas mehr vom Programmieren. Was das jetzt schon an Zeit gefressen hat - meine und Eure ...
*g* -dnh -- Versäumen sie nicht den neuen Film von Albert B. Blumenkohl ---===### "To live and let rub" ###===--- Aus dem Inhalt: "Mein Name ist Gross. Flo Gross. Mein Schlauch auch. Geben Sie mir eine Kampflesbe bitte, eine gerührte. Nein, geschüttelt. Wo ich sie doch viel lieber gerieben hätte." [Sig von 'Moss' in suse-talk]
participants (3)
-
Alfred Poschmann
-
David Haller
-
Martin Schmitz