Am Montag, 7. Juli 2003 13:04 schrieb Thomas Hertweck:
Joerg Thuemmler wrote:
<IMHO> unresolved symbols heißt i.allg. daß beim Linken in Programmteilen Symbole (Variablen, Funktionen...) verwendet werden, die dort nicht angelegt werden (d.h. i.allg. werden sie als extern definiert o.ä.). Der Linker hat den Inhalt dieser Symbole aber auch in den anderen Bibliotheken oder Quellen, die zum Projekt gehören, nicht finden können. Es kann natürlich sein, daß diese Symbole gar nicht benötigt werden, aber das ist allenfalls bei großen Projekten oder bei Dingen, die verschiedene Architekturen abdecken, wirklich zu erwarten.
Bei Modulen ist das etwas anders. Compilieren kann man die schon, ohne dass es zu Problemen kommt, und eben auch installieren (gelinkt wird da ja nicht).
Hmm, bei meinem Modemtreiber war es halt gerade so, _daß_ er gelinkt werden mußte... es wurden per Compiler einige kernelspezifische Sourcen erzeugt und mit dem proprietären Zeugs von SmartLink (archtek) verlinkt, und genau da kamen dann die "unresolved symbols"-Fehler und das make brach ab.
Fuehrt man dann allerdings ein "depmod" aus und es wird versucht, die Abhaengigkeiten der Module aufzuloesen, hagelt es "unresolved symbols". Das ist wohl beim urspruenglichen Fragesteller in diesem Thread passiert. Auch beim Linken des Kernels (vmlinux) kann es zu diesem Problem kommen; dort faellt es aber eher auf, weil dadurch dann gar kein Kernel erstellt wird und das "make bzImage" mit einem Fehler abbricht.
es ging IMHO nicht um einen Kernelbuild, sondern darum mittels der Kernelheader den Modemtreiber zu erstellen und ich denke weiterhin aufgrund meiner eigenen Erfahrungen, daß die Treiber-"quellen" auf einen bestimmten Kernel eingestellt sind, wahrscheinlich einen mit bestimmten patches und eben nicht mit jedem anderen compiliert und ggf. gelinkt werden können. IMHO sind von den Herstellern gelieferte Hardwaretreiber eben oft partiell objectcode um die eigenen Techniken aus der GPL rauszuhalten und dem user zu überlassen, sie mit GPL-code zusammenzusetzen, dazu gibts dann die uncompilierten C-Sourceschnippsel im Treiberpaket. Meinen Kernel bekomme ich jedenfalls seit der Installation meines Modemtreibers nun immer als "tainted" angezeigt, aber dazu gibts keine Alternative...
Ich habe bei meinem Laptop - für dessen SmartLink-Modem es nur proprietäre Treiber für bestimmte RedHat Kernel gab, diesen Fehler immer bekommen, wenn ich versucht habe, die Treiber für einen anderen - und sei es einen fast versionsgleichen - Kernel zu erstellen. Zu brauchen waren die dann nie. (Glücklicherweise kann man den neuesten SmartLink-Treiber auch für den Kernel der 8.1er Suse nehmen, sie sind etwas kompatibler geworden).
Module mit "unresolved symbols" koennen nicht geladen werden. Wie sollen sie auch ihre Funktion erfuellen, wenn ihnen die Implementierung einer Funktion o.ae. fehlt!?
logo. Ich meinte ja, daß das Linken bei der letzten Version fehlerfrei lief.
Also ich denke, wenn Du wirklich alle nötigen Quellen und Module installiert hast und ggf. in den Makefiles die richtigen Pfade dazu stehen, dann wird es mit diesem Kernel evt. nicht klappen, steht da nix in einer Readme? </IMHO>
Wenn es sich um keine externen Module, sondern schlicht um Module, die aus dem Kernel-Tree erzeugt wurde, handelt, dann ist die Kernel-Konfiguration fehlerhaft. Wenn ich z.B. ein Modul baue, was ACPI braucht, ich ACPI aber bei der Kernel-Konfiguration abgestellt habe, dann wird das Modul vermutlich compilieren, aber nach dem Installieren werden duch depmod "unresolved symbols" gemeldet werden, weil die Implementierung von ACPI dann fehlt (hatte ich ja abgestellt bei der Kernel-Konfiguration). Das wird nicht durch ein "make dep" ueberprueft, wie viele immer annehmen. Ein "make dep" erzeugt nur Abhaengigkeiten der Dateien untereinander zum Compilieren des Kernels (und erstellt nebenbei noch ein paar Header-Dateien aus der Kernelkonfiguration), nicht mehr.
Gruesse, Thomson
Habe nix anderes behauptet. Aber es ging im Thread einfach nicht um Kernelbuild, sondern u.a. darum daß der Compiler die modversions.h brauchte, um den Treiber zu bauen. Eben das wollte meiner auch, und die "unresolved symbols" kamen trotzdem, weil ihm die modversions.h oder andere Kernelheader eben nicht gefielen... Und das lag bei mir reproduzierbar an der Kernelversion. -- Joerg Thuemmler sysadmin@vordruckleitverlag.de