Hallo, On Tue, 12 Feb 2002, Christoph Maurer wrote:
Am Sam, 09 Feb 2002 schrieb David Haller:
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:
Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine.
Da nicht. Aber sehr wohl in /usr/include/linux und /usr/include/asm. Und bei mir ist, seit 2.2.10 (aber ich hab's seit 2.0.35 so gehalten) ist (rechte/datum gekuerzt)
# ls -alF /usr/include/linux /usr/include/asm /usr/src/linux /usr/include/asm -> ../src/linux/include/asm/ /usr/include/linux -> ../src/linux/include/linux/ /usr/src/linux -> linux-2.4.16/
War ja auch lange bei den Distributoren so gehalten und seit 7.2 ist SuSE wieder davon abgegangen.
Aha :)
Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC.
Mag sein. Aber ich wuerde Linus da widersprechen. Warum?
Vielleicht solltest Du das mal auf der lkml mit ihm besprechen, würde mich interessieren, was dabei rauskommt.
Mmmm... Dazu muesste ich Linus' Argumentation erstmal genau lesen... (danke fuer die URL). Was ich schrieb, war schlicht aus meinem Verstaendnis des Zusammenspiels von libs/headern/kernel heraus...
Szenario:
Schritt 1: libc-foo wird gegen kernel-2.2.x kompiliert, und verwendet also das kernel-api-2.2.x. Soweit, so gut, keine Diskussion. Ob die Header dabei die vom Kernel sind, oder bei der libc "dabeiliegen" ist irrelevant.
ACK.
*g*
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/
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"!
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). Was interessiert's wenn es nicht nur 'int foo', sondern zusaetzlich noch ein 'int bar' gibt, solange es 'int foo' noch gibt? Probleme gibt's, wenn 'int bar' gewollt wird, aber es nur 'int foo' (und nicht beide) gibt...
Wenn Du jetzt nicht weißt, woran das liegen könnte, wirst Du als Programmierer doch bekloppt.
s.o. irrelevant.
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.). Wie gesagt: was nicht verwendet wird ist irrelevant. Probier's mal aus: Verwende eine glibc-2.0 funktion mit glibc-2.2. Verwende ne glibc-2.2 Funktion (die's in 2.0 noch nicht gab) mit 2.0... Und was "ueberfluessigerweise" noch in Headern deklariert wird, ist dabei auch egal...
b) Update der libc auf Version bar Verwendet das api von kernel-<auchegal> Folgerung: wenn libc-bar auf dem api von kernel-2.4.x beruht, macht's "PENG" wenn man noch kernel-2.2 verwendet und ein in 2.2 nicht vorhandenere syscall aufgerufen wird. [..] Gebe Dir recht, das es wohl keine gute Idee ist, eine libc zu verwenden, die gegen einen neueren Kernel, als der von einem selbst eingesetzte, kompiliert wurde, zu verwenden.
"Keine gute Idee" ist untertrieben... Entweder es klappts (siehe oben), oder es klappt eben (komplett!) nicht...
c) beides updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} da nun auch die libc das passende api verwendet
Geht aber nur, wenn Du nur eine Kernel-Version parallel verwendest. Ist bei mir nicht unbedingt so.
# ls /boot/vm* /boot/bzI* /boot/2.2.1*/{bzI,vm}* | wc -l 35 Wie meinen? /me und nicht mehrere Kernel??? Du kennst mein "mini-Howto" zu dem Thema? Warum hab ich das wohl geschrieben? *eg*
d) nichts updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} siehe c).
Fazit: Linus liegt IMO falsch.
IMHO nicht.
<repeat ad infinitum> *eg*
Ich verwende hier eine glibc-2.1.3 (gegen 2.2.10 kompiliert!) und Kernel 2.4.16 und kann mir beim besten Willen nicht vorstellen, dass ein verwenden des 2.2.10er Kernel-apis alles gut gehen wuerde.
Verwende eine lib 2.1.? gegen Kernel 2.2.16 kompiliert und seitdem einige 2.2er und 2.4er Kernel (mittlerweile 2.4.14) und /usr/src/linux zeigt immer auf die Includes des 2.2.16er Kernels -> nie Probleme.
Eben. Ich ja auch. Das Kernel-Api _ist_ eben (zum Glueck) abwaerts- kompatibel (zumindest zwischen 2.2.x und 2.4.x, gegen 2.0.x gibt's AFAIR ein paar Inkompatibilitaeten... Mehr als das der glibc, IIRC.
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!
Achso: Ich sollte wohl noch betonen, (worueber es AFAIR bei diesem
Streit auch geht), dass