Am Don, 2003-06-12 um 15.18 schrieb David Haller:
Hallo,
On Thu, 12 Jun 2003, Patrick JOERG wrote: [snip, irrelevant ;)]
ixpio wurde für Slackware geschrieben und verwendet die includes von den Kernelsourcen, und erwartet einen Link auf diese namens /usr/include/linux. Da unter /usr/include bereits ein Ordner "linux" mit includes ist habe ich beim installieren von ixpio aus diesem Ordner ein "linux_alt" gemacht :(....(sehr schlecht)
Noe. IMO im Gegenteil. IMO sollte(!) /usr/include/linux ein symlink auf die includes (/usr/src/linux/include/linux) des aktuell verwendeten Kernels sein. Das war mal .. Siehe unten.
Ich nehme an, dass das früher oder später ein Problem sein wird,
Das ja.
Aber "frueher oder spaeter" bekommst du _immer_ Probleme. Egal, ob /usr/src/linux nun die Kernel-Header enthaelt, gegen die die glibc gelinkt wurde (das sind die, die du vorgefunden hast), oder ob diese die des aktuellen Kernels sind.
deshalb meine Frage: Wie kann man das besser lösen,
Gar nicht (s.u.).
oder grundsätzlich, was wird im original /usr/include/linux eigentlich anders gemacht.
s.o. "original" sind dort die Kernel-Header, gegen die die (g)libc gelinkt wurde.
So, jetzt aber noch die Kurzfassung meiner "Rationale" warum _ich_ lieber die Header des aktuellen Kernels in /usr/include/linux haben will:
Tatsache: Es wird dich frueher oder spaeter, auf die eine oder andere Weise so oder so erwischen.
These (vertreten mind. von mir ;): Verwendest du die Header des aktuellen Kernels erwischt's dich bei Inkompatibilitaeten a) beim Kompilieren/Linken, oder b) dein System laeuft sowieso nicht (richtig/sauber), weil die libc nicht mehr zum Kernel passt. Laesst es sich also kompilieren und linken, sollte es auch laufen.
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,
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. * /lib/modules/<kernel-version>/build enthält die Quellen der Kernel-Version <kernel-version>; Ist meist ein Symlink auf /usr/src/linux-<kernel-version>, kann aber auch ein echtes Verzeichnis sein. * /usr/src/linux-<kernel-version> enthält die zur Kernelversion <kernel-version> gehörigen Quellen. * /usr/src/linux gibt es bei manchen Distris nicht mehr (z.B. RH-9) => 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. Ralf