Hallo, On Thu, 12 Jun 2003, Ralf Corsepius wrote:
Am Don, 2003-06-12 um 15.18 schrieb David Haller: [..]
Antithese (vertreten IIRC u.a. von Linus und P. Thomas[1]): Verwendest du die Header, gegen die (g)libc kompiliert wurde, passt deine App zur libc. Ob diese (Kombination) aber auch zum verwendeten Kernel passt, stellst du fruehestens aber zur Runtime fest, u.U. durch einem "netten" Panic oder so erhellende Fehlermeldungen wie einen SEGFAULT...
Der entscheidende Vorteil für Distributoren: Er kann den Kernel jederzeit austauschen, ohne dass Apps/Libs recompiliert werden müssen. Der Distri muss (und kann!) dabei allerdings aufpassen, dass Kernel gegenüber der Glibc kompatibel bleiben. D.h. ein Kernel muss ggf. an die glibc angepasst werden,
Das ist der Knackpunkt, siehe mein Beispiel unten. Eine "zu einem Zeitpunkt" zusammegestellte Distri ist natuerlich "einfach", da bekommt man i.d.R. keine Probleme. Probleme bekommt man ja immer dann, wenn sich das Kernelinterface aendert.
Synthese: Besser frueher (beim Kompilieren oder linken), als spaeter (zur Runtime)... Ergo...? Na? *g*
Man moege mich widerlegen... (wie gesagt: erwischen tut's einen _immer_, das ist also _kein_ Argument!) :) Rein technisch betrachtet ACK, aber in der Praxis belanglos, da ...
... praktisch alle modernen Linuxdistris folgendes Schema verwenden:
* In /usr/include/linux liegen die Header des Kernels, mit denen die glibc compiliert wurde.
Was ich eben fuer nicht sinnvoll halte, da dann die glibc-Kernel-Header
verwendet werden, wenn man z.B.
* /lib/modules/<kernel-version>/build enthält die Quellen der Kernel-Version <kernel-version>;
Das gab's noch nicht, als meine glibc erstellt wurde.
* /usr/src/linux-<kernel-version> enthält die zur Kernelversion <kernel-version> gehörigen Quellen.
Ack.
=> Will man Kernelmodule übersetzen, sollte man entweder -I/usr/src/linux-<kernel-version>/include oder -I/lib/modules/<kernel-version>/build/include verwenden.
Will man Applikationen übersetzen, auf keinen Fall -I/usr/src* oder -I/lib/modules* verwenden.
Jein. Wie gesagt, da /usr/include/linux bei mir ein symlink nach /usr/src/linux/include/linux (oder wg. mir auch nach /lib/modules/`uname -r`/build/include/linux) ist, muss ich gar kein -I angeben. Waere das nicht der Fall, faellt man auf die Nase -- und zwar erst zur Laufzeit. Konkretes Beispiel bei mir neulich: kcmjoy (KDE1) tat nicht mehr, da noch fuer Kernel 2.2.x. Meine glibc wurde unter Kernel 2.2.10, .12 oder .14 erstellt (SuSE 6.4). Enthielte bei mir /usr/include/linux die glibc-Kernel-Header, so haette beim kompilieren kcmjoy wieder die 2.2.x-Header genommen und immer noch nicht getan (hab's getestet, kcmjoy lief schlicht nicht). Ich habe kcmjoy also dazu gezwungen, die aktuellen Header (2.4.16) zu verwenden, und siehe da: kcmjoy laeuft _ohne Aenderungen im code_ auch mit Kernel 2.4.16 -- nur die richtigen Header musste ich verwenden und zwar eben _nicht_ die der glibc. Wie gesagt: Akut wird das Problem (nur) dann, wenn sich das Kernelinterface aendert, wie z.B. zwischen 2.2.x und 2.4.x bei joystick. Eine "konsistent" erstellte Distribution ist uninteressant fuer diese Betrachtung. Hat hier jemand noch ne SuSE die mit 2.2.x und 2.4.x ausgeliefter wurde? Wie hat SuSE das dort z.B. bei joystick.h gemacht? "Gegen" welchen Kernel wurde da die glibc erstellt? -dnh -- It takes a million monkeys at typewriters to write Shakespeare, but only a dozen monkeys at computers to run Network Solutions. -- Patrick Delahanty