Hallo, On Wed, 13 Feb 2002, Christoph Maurer wrote:
Am Mit, 13 Feb 2002 schrieb David Haller:
On Tue, 12 Feb 2002, Christoph Maurer wrote:
Am Sam, 09 Feb 2002 schrieb David Haller:
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:
[/usr/src/linux link auf verwendete Kernelquellen oder auf includes, gegen die glibc kompiliert wurde] unterstützt, gehe aber mal davon aus (ohne es belegen zu können), daß [das kernel-api] weitgehend abwärtskompatibel gehalten wurde.
Ja wird es. Und das ist gut. In gewissen Grenzen (siehe M$, siehe meine Erfahrungen (libc gegen 2.2.10, kernel 2.4.x).
Aber das ist nicht "garantiert" fuer 2.6 oder ... Und wenn, dann will ich Probleme beim kompilieren "mitbekommen"!
Sicher, da gibt es bestimmt Grenzen, aber solange die Kompatibilität im Rahmen eines Versionssprungs (2.2->2.4 bzw. 2.4->2.6) gewahrt bleibt, sollten die meisten Benutzer damit leben können. Oder willst Du Deine 6.2 auch in ca. 2 Jahren, wenn man 2.6 benutzen kann, noch verwenden :)
Warum nicht? Meine 6.2 ist sowieso schon, mompl... $ rpm -qa --queryformat "%{installtime} %{name}\n" | sort -n | head -1 934823966 bc $ epochtodate 934823966 Mon 16.08.1999 19:19:04 CEST ... ca. 2 1/2 Jahre alt, da macht's nimmer viel, wenn die noch aelter wird :) Is natuerlich vieles aktualisiert bzw. selbstkompiliert... Wenn ich (demnaechst evtl.) mal wieder neu installiere, dann vermutlich eh keine Susi, sondern LFS oder (vielleicht) ne Debilian... *eg*
Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben.
Nein, eben nicht(!). Nicht verwendete Funktionen sind irrelevant. z.B. ist der Grossteil der glibc-2.2 noch "identisch" zur glibc-2.0. (sieh dir mal ein 'nm' eines gegen die glibc-2.2 gelinkten binaries an).
Ja, aber was ist, wenn Du als Programmierer einen Aufruf, korrekt gemäß Header-Files, verwendest, der aber nicht gelinkt werden kann, da in verwendeter glibc noch nicht implementiert.
Oder noch schlimmer, und darauf bezieht sich Linus in u.g. URL, wenn eine neuere Version eine struct X reimplementiert.
Jep. Aber: siehe z.B. http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0616.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0625.html Das ganze sieht mir eh ziemlich wuest aus... IMO entsteht der "nicht aufloesbare" Konflikt dann, wenn structs (u.ae.) im Kernel geaendert werden (nicht nur "erweitert"[1]), aber dabei nicht umbenamst werden.
IMHO gibt es keine andere Alternative, als beim arbeiten mit Bibliotheken und Include-Dateien, die exakt zueinander passenden Versionen zu verwenden.
Noe. Ich habe schon mehrfach Programme gegen (angeblich) zu alte libs erfolgreich gelinkt, weil die Programme nicht wirklich die neuen Funktionen verwendeten (u.a. gegen libc, libgtk, libgnome u.a.).
Ist ja logisch, IIRC meine Vorlesung in Internprogrammierung, bietet die Bibliothek so eine Art Inhaltsverzeichnis am Anfang, wo Du über den Namen die Einsprungadresse findest. Solange alle gewünschten Namen (i.e. im Wesentlichen unter C alle Funktionsnamen, bei C++ wirds komplizierter, ist aber hier nicht das Thema) aufgelöst werden können, klappt das Linken.
ACK. Ich sehe mein "zu kurz" Denken, ISC. ;) Aber s. [1] und die o.g. Urls, auch Linus' kategorisches "keine symlinks" ist "zu kurz" gedacht, und (lt. der Mail, zu der du die URL gemailt hast), verwendet er eine aehnlich "inkonsistente", aber "entgegengesetzte" Konstellation, die (genau wie meine wohl) klappt, weil der Kernel eben abwaertskompatibel ist :) (IIRC ist meine glibc auch gegen 2.2.10 gelinkt, und ich verwende Kernel 2.4.x *lol*)
[...] <repeat ad infinitum> *eg*
Na, ich hoffe nicht, bisher ist die Diskussion auf jeden Fall noch fruchtbar.
Ack!
FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html
Merci.
Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird.
Genau. Eben. Mehr als die glibc. Ergo: /usr/src/linux -> linux-${current_version}.
Denn so bekommt man ggfs. auftretenden Inkompatibilitaeten mit!
Dafür bekommst Du u.U. Compilerfehler, wo es überhaupt kein Problem gibt.
Dazu kann ich nur sagen: na immerhin das! Da weiss ich wenigstens, dass etwas schiefgeht. Ein "kommentarloses" durchkompilieren hilft mir bei so einem Konflikt (in beiden Szenarios) nicht, wenn ich dann "vertrauens- voll" den scheinbar fehlerlos kompilierten Kernel testen will... Generell: Compiletime Fehler (egal welcher Art!) sind mir immer lieber als Runtime-Fehler. Achso, zu dem was Linus meinte: ich denke, ich weiss zumindest teil- weise, was ich tue, wenn ich den symlink setze... :)
Achso: Ich sollte wohl noch betonen, (worueber es AFAIR bei diesem Streit auch geht), dass
IMO _KEINE_ libc header sind, sondern Kernel-header, siehe meine bisherige Argumentation. Ja, die einmal für die Kompilierung der libc herangezogen werden und dann deshalb libc-Header sind.
Nein. Es sind die Kernel-header, gegen die die libc kompiliert wurde. Hey, ein libc Entwickler koennte sonst ja, in einem "libc-pseudo-kernel- header" sonstwas deklarieren, z.B. 'struct X { char c; }' statt 'struct X { int foo; }'... Wenn das nicht zum Kernel passt... Ich meine, die libc kann ueber den Kernel behaupten was sie will, entscheidend ist, was in _meinem_ Kernel drin ist. Wenn's Konflikte gibt, sind das libc Konflikte, denn die glibc ist "userland", genau wie jede andere lib, die auf syscalls, ioctls oder sonstige Kernelfunktionen/-features zugreift. Dass die libc "eigene" kernel-header mitbringen soll(te) ist IMO Schwach- fug. Die koennte ja, wie gesagt, Kernel 0.0.99 header oder sonstwas mit- liefern... (klar, siehe Linus' oder meine Konstellation, es geht "lange" gut, aber nur eben bis...). Es macht natuerlich weder Sinn nen aktuellen Kernel mit ner uralt libc, oder ne aktuelle libc mit nem uralt Kernel zu verwenden...
Kernel-header sind und bleiben Kernel-header, egal was die libc dazu meint. Wenn dann eine Inkompatibilitaet auftritt will ich das wissen, und nicht durch (zu alte) libc-pseudo-kernel-header verdeckt wissen. Nach letzterm Schema koenntest du ne gegen Kernel 1.0 kompilierte libc mit kernel-1.0-headern verwenden, aber dann nen 2.5.x Kernel verwenden, ohne dass das beim kompilieren auffallen wuerde -- aber wetten, dass das dann zur Laufzeit schiefginge?
s.o. alles hat Grenzen und Dein Ansatz schließt sowas sicher aus.
Eben.
Aber wer will das oben skizzierte?
Ich! Wenn auch nicht unbedingt so extrem :)
Du hast mich davon überzeugt, daß es Szenarien gibt, in denen die von mir propagierte Vorgehensweise Fehler zur Laufzeit gibt, die Du ausschließen kannst, nämlich immer dann, wenn die Abwärtskompatibilität des Kernels aufgegeben wird. Vielleicht sollte man im Kernel angeben, bis zu welcher Version er abwärtskompatibel ist.
Genau. Siehe [1] :). IMO stimmt beides *lol*. Die Frage ist, welche Strategie man zur "Konfliktaufdeckung" moechte...
Genauso kann es aber IMHO bei Deiner Vorgehensweise zu Laufzeitfehlern kommen, da Deine (so verstehe ich zumindest Linus Argumentation) alte libc bei Reimplementierungen einer Datenstruktur den alten (in der neuen Kernelversion aus Gründen der Abwärtskompatibilität weiterhin enthaltenen) syscall aufruft (der natürlich auch noch die alte Datenstruktur erwartet), aber gemäß der Informationen zur Compilezeit schon die neue Datenstruktur verwendet. Das wird beim Kompiliern nicht auffallen (da allein Header ausschlaggebend) beim Linken aber auch nicht, da die Strukturen den gleichen Namen haben und somit der Linken keinen Grund zum Meckern sieht.
Ack. Und das ist dann IMO ein Fehler (s. [1]) im Kernel. Insgesamt eine ziemlich unschoene Situation, fuer die's (tippe ich mal) nur die Loesung der korrekten Versionierung der Kernelsymbole gibt, wo dann eben die glibc (oder sonst eine lib/Programm) eben eine bestimmte (Mindest-)Version eines Symbols verlangen kann, wie auch bei der glibc. -dnh [1] ein struct X { int foo; int bar; } ist doch AFAIK "rueckwaertskompatibel" zu struct X { int foo; } da foo "noch da ist", und "dass da noch mehr drin is", ist AFAIK egal. Ein struct X { int bar; } hingegen nicht. Eine Versionierung der Kernelsymbole wie in der glibc waere aber IMO eine gute Idee. Wenn da z.B. ein Programm "struct X@kernel_2_0" verlangt, und diese auch noch im Kernel 2.6 drin ist, ist alles in Butter, wenn die Struktur ohne Umbenamsung geaendert wird, waere es eben dann struct X@kernel_2_0 und der linker koennte den Konflikt erkennen (siehe die Ausgabe von nm bei einem beliebigen gegen die libc gelinkten Programm...) -- We have joy, we have fun, we have Linux on our SUN -- from a sig of Peter Lemken