Hallo Zusammen Ich arbeite an einem Projekt für einen Strassendrucker. Dabei verwenden wir SuSE 8.0. Wir programmieren mit Qt und RTAI als Echtzeiterweiterung. Zusätzlich brauchen wir ein Modul von http://www.icpdas.com/. Dabei folgendes Problem: 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) Ich nehme an, dass das früher oder später ein Problem sein wird, deshalb meine Frage: Wie kann man das besser lösen, oder grundsätzlich, was wird im original /usr/include/linux eigentlich anders gemacht. Vielen Dank für Hilfe jeglicher Art Patrick Jörg HTA Burgdorf Schweiz http://www.isburg.ch/m/dip/index.htm
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.
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... 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!) :) Philipp, dein Stichwort... *SCNR* Oder hast du inzwischen deine Meinung geaendert? Oder hab ich diese sogar flscha in Erinnerung? Falls ja, mea culpa.... -dnh [1] bitte korrigiert mich ggfs.! -- 69: WWW World Wide Windows
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
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
participants (3)
-
David Haller
-
Patrick JOERG
-
Ralf Corsepius