On 17.Aug 2003 - 04:23:07, Seth wrote:
> Ich hab da eine Verst�ndnisfrage.
>
> Als ich meinen nvidia Treiber Compilieren wollte, fragte er nach den
> Kernel-Headern, da er kein passendes Kernelimage finden konnte.
Nee, so ganz ist das nicht richtig. Du hast einen Kernel per Kernelimage
installiert - also nicht selbst kompiliert. Daher hast du nicht die f�r
deinen Kernel benutzten C-Headerdateien, welche der Treiber aber
ben�tigt weil die in dem Quellcode des Treibers benutzt werden. Ja der
Treiber hat Quellcode, obwohl er ClosedSource ist, er muss n�mlich f�r
jeden Kernel f�r den das Modul installiert werden soll eine
Schnittstelle kompilieren zwischen dem Kernel und dem vorkompilierten
Binary.
> Das kann ich nachvollziehen, da mit einem neuen Kernel neue Funktionen
> kommen (im wahrsten Sinne des Wortes) und der Treiber, welcher ja
> kompiliert werden muss, muss diese Kennen.
Muss er auch nicht, der Treiber kennt nur die alten Funktionen. Wie
stellst du dir das vor, das er s�mtliche Headerdateien einliest und dann
daraus lernt? Nee, er braucht halt einige Kernelfunktionen, die sog.
Signatur dieser Funktionen stehen in den Headerdateien. Mit Signatur ist
damit gemeint der Name der Funktion, der R�ckgabewert und die Parameter
die sie �bernimmt. Dass muss man in dem C-Quellcode definieren um die
Funktion nutzen zu k�nnen.
> Nun hat der Treiber aber noch rumgemeckert, das die Compiler Version
> (via CRC-Check �berpr�ft) nicht stimmen w�rde und das deshalb die
> installation abgebrochen w�rde.
Ich weiss leider nicht warum er das macht, denn der Bin�rcode den die
Gnu-Compiler liefern ist zwischen allen Versionen kompatibel die so im
Einsatz sind. Vielleicht gibts da andere Gr�nde, jedenfalls hatte ich
bisher noch kein Problem damit den Treiber mit gcc-3.3 und den Kernel
mit gcc-3.2 zu kompilieren.
> Ich habe zuerst nicht verstanden, warum der Compiler dabei eine Rolle
> spielt.
>
> Ja, ich bin kein Programmierer. ;)
>
> Da ich aber auch nach Informationen f�r die glibc gesucht habe, da ich
> herrausfinden wollte, ob ich nicht einfach alle Versionen Installieren
> kann, und ich irgendwie keine Download-Sourcen gefunden habe UND auch
> mal kurz nachgedacht habe, bin ich darauf gekommen, das die jeweiligen
> Libs wohl mit den jeweiligen Compilern kommen, also nichts
> "eigenst�ndiges" sind. *pling* :)
So ungef�hr, wobei man die libc6 (glibc) nicht in mehreren Versionen
ben�tigt, die sind untereinander alle voll bin�r kompatibel. Dagegen
gibts wohl immernoch Programme die die alte libc5 ben�tigen und die
gibts bei Debian als Paket. Anders hingegen ist das bei den Standard-C++
Bibliotheken, die auch zu dem jeweiligen Compiler geh�ren. Dort haben
sich in den letzten paar Versionen immer wieder die Bin�rinterfaces der
damit kompilierten Bibliotheken ver�ndert. Dadurch sind Programme die
mit der Version gcc-2.95 kompiliert wurden nicht mit Bibliotheken
benutzbar die mit dem gcc-3.2 kompiliert wurden. Seit gcc-3.2 ist das
aber wieder stabil, so dass es egal ist ob mit gcc-3.2 oder gcc-3.3
kompiliert. Beim Kernelmodulen ist aber das letztgesagte total egal, da
Kernelmodule in C geschrieben sind, deswegen verstehe ich den Check des
NVidia-Treibers auch nicht.
> Dann stellt sich mir aber noch die Frage, warum der Treiber sich nicht
> kompilieren lie�, wenn die Funktion an sich, der jeweiligen Funktionen
> doch die selbe ist.
Was hat er denn an Fehlermeldungen so gebracht?
> Auf einer Seite die ich hier auch gepostet habe, habe ich gelesen das es
> Kernel-Code und, uhm, naja, nicht-Kernel-Code gibt. ;)
In dem einen Treiber? Nee, es gibt dort allerdings schon fertig
kompilierten Objectcode. Ansonsten ist Kernel-Code genau wie jeder
andere C-Code auch. Allerdings ist es f�r Programme ein Unterschied ob
sie im sog. Kernelspace oder im Userspace ausgef�hrt werden. Das heisst
ob es sich um Programme handelt die direkt an den Kernel angebunden sind
und damit auch Kernelinternen Schnittstellen nutzen k�nnen oder ob die
Programme die �ffentlichen Schnittstellen des Kernel nutzen m�ssen.
> Somit w�ren die Libs wiederum Kernelabh�ngig.
N�, das w�re ja auch schlimm. Jedesmal wenn eine neue Kernelversion
kommt muss man alle Bibliotheken neu kompilieren iiihhh ;) Der Kernel
definiert halt bestimmte Systemrufe, die z.B. von der Libc6 in
C-Funktionen umgesetzt werden (so ungef�hr ist es jedenfalls). Und die
weiteren Bibliotheken nutzen dann die libc6 um z.B. Dateien zu �ffnen...
Aber auch die libc6 ist nicht kernel-abh�ngig, da der Kernel halt
Schnittstellen definiert die sich nicht (oder nur sehr selten) �ndern.
> Also, bevor die Mail ein ungewolltes ausma� annimmt, w�re ich f�r
> kl�rende Links dankbar.
W�sste ich jetzt so auf Anhieb nix, aber du k�nntest dir Mal die Doku
unter /usr/share/doc zu gcc und libc6 und die Kernel-Dokumentation
angucken. Auch der Kernelquellcode kann sehr aufschlussreich sein,
nat�rlich muss man daf�r ein wenig C verstehen.
Andreas
--
Man glaubt einem Mann von Talent mehr, was er versichert, als was er
beweiset - Hier untersucht man erst seine Beweise, dort ist er einer.
-- Jean Paul
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
