David Haller schrieb:

...

dann fuehre ich make aus und er bricht ab mit:

cpp0: /usr/src/linux/include/linux/modversions.h no such file

Das ging erst heute ueber die Liste, du musst die Kernel-Sourcen installieren und konfigurieren. Oops, das Installieren ist fertig. Aber was meinst Du mit configurieren? Das mach ich zum erstem Mal? Wo muss ich nachlesen? Was muss ich tun?

Thomas Hertweck schrieb:

toRBEN pOLLmann schrieb:

...

[...cpp0: /usr/src/linux/include/linux/modversions.h no such file...]

Aber was meinst Du mit configurieren? Das mach ich zum erstem Mal? Wo muss ich nachlesen? Was muss ich tun?

Installiere die zum Kernel 2.4.XX.SuSE passenden Kernel-Quellen. Man findet sie auf der SuSE DVD/den SuSE CDs (ausser bei der "Private" Version) und kann sie per YaST2 installieren. Gehe in das Verzeichnis /usr/src/linux und fuehre dort ein "make cloneconfig" als root aus. Ueberpruefe im Anschluss, ob in der Datei .config "CONFIG_MODVERSIONS=y" steht. Sollte dort "# CONFIG_MODVERSIONS is not set" stehen, aendere das ab. Fuehre im Anschluss ein "make dep" aus. Danach wird es die Datei /usr/src/linux/include/linux/modversions.h geben und Du kannst mit Deinem urspruenglichen Vorhaben fortfahren.

YEEEEEAH I GOT IT GOING!!! Sollte ich jetzt einen Report posten? Macht es was, wenn er meckert, dass in 3 Files noch unresolved symbols sind? Und letzte Frage, ich installiere jetzt gleich den ppp Login unter Linux: Kannst Du mir in 3 kurzen Saetzen sagen, was ich mit make dep genau gemacht habe (den Rest habe ich verstanden) Danke!!!!! Nochmal: DANKE! TOPMANN!

* Thomas Hertweck schrieb am 05.Jul.2003:

"make cloneconfig" - wie der Name auch schon sagt - klont die Konfiguration, die zum aktuell laufenden SuSE-Kernel gehoert. Dadurch wird die Datei .config erstellt - sie enthaelt nun die Konfigurationsangaben. Durch ein "make dep" werden nun zum Compilieren noetige Abhaengigkeiten (dependencies) zwischen den Dateien aufgeloest und in den Dateien .depend gespeichert. Wenn Du Dich mal mit "make" beschaeftigst, wirst Du dieses Vorgehen sehr schnell verstanden haben.

Nun ja, das Makefile des kernel ist nun auch nicht das einfachste zu verstehende. Überhaupt sind die ganzen Makefiles auch die der tarballs ein wenig heavy für den Anfang. Ist halt der Nachteil, wenn der tarball auf viele sehr verschiedene Architekturen laufen soll. Wenn man make lernen will, dann sollte man mit sehr viel einfachere Makefiles anfangen. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0

Thomas Hertweck :

cloneconfig" als root aus. Ueberpruefe im Anschluss, ob in der Datei .config "CONFIG_MODVERSIONS=y" steht. Sollte dort "# CONFIG_MODVERSIONS is not set" stehen, aendere das ab.

Sorry, aber das halte ich für unnötig. Und wozu auch? Philipp

Philipp Thomas schrieb:

Thomas Hertweck :

...

cloneconfig" als root aus. Ueberpruefe im Anschluss, ob in der Datei .config "CONFIG_MODVERSIONS=y" steht. Sollte dort "# CONFIG_MODVERSIONS is not set" stehen, aendere das ab.

Sorry, aber das halte ich für unnötig. Und wozu auch?

Philipp

Kann daher der unresolved symbols Error kommen?

Am Sonntag, 6. Juli 2003 10:19 schrieb Philipp Thomas:

toRBEN pOLLmann [Sun, 06 Jul 2003 09:22:48 +0200]:

...

Kann daher der unresolved symbols Error kommen?

Nein.

Philipp

<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. 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). 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> HTH -- Joerg Thuemmler sysadmin@vordruckleitverlag.de

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