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]
Schritt 2: Updates...
a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. [..] Ich gebe Dir recht, daß es ein Problem sein könnte, wenn der Kernel in den original Headeren deklarierte Aufrufe nicht mehr
s/original/libc/
Ja, natürlich.
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 :)
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.
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.
[...] <repeat ad infinitum> *eg*
Na, ich hoffe nicht, bisher ist die Diskussion auf jeden Fall noch fruchtbar.
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.
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.
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. Aber wer will das oben skizzierte? 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. 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. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen