Thorsten Kukuk wrote:
On Tue, May 01, Ralf Corsepius wrote:
Die entscheidende Fragen wären, * wohin /usr/include/[linux|scsi|asm] und /usr/src/linux zeigen, bzw. was sie beinhalten.
/usr/include/scsi kommt, wie schon immer, aus der glibc,
[ Randbemerkung:Zu libc5 Zeiten kamen sie aus dem Kernel und wurden laut glibc-cvs am 7.9.97 der glibc2 hinzugefügt (IIRC, war dies ungefähr der Zeitpunkt an dem das scsi/sg.h Problem aufkamen und der berühmte Streit zw. UD und LT aufbrach.). Wie ein Blick auf meine noch vorhandene SuSE-6.0 zeigt, war scsi/sg.h Bestandteil der glibc2, alle anderen nicht.]
* wie die Config-Header (linux/config.h, linux/autoconf.h) unter /usr/include/[linux|..] behandelt werden
Die haben da gar nichts verloren. Gut, so sehe ich das auch.
Nur DAS ist etwas ganz anderes als "Die Kernelheader des Kernels mit dem die glibc übersetzt wurde nach /usr/include zu kopieren", wie es von anderen auf dieser Liste propagiert wird.
Wenn Dein Programm die braucht machst Du wieder etwas falsch. Ein Userland-Programm sollte niemals auf eine spezielle Kernel-Konfiguration angepaßt sein, sondern mit jeder klarkommen. ACK.
Z.B. wäre ein mit der glibc kommendes /usr/include/linux/autoconf.h ohne jeglichen sinnvollen Inhalt, da kein Zusammenhang zum verwendetet Kernel besteht. Da autoconf.h von config.h included wird, config.h aber z.B. auch von fs.h included wird, wären auch diese sinnlos. D.h. die Header
Was juckt Dich linux/fs.h ? Wenn Du die brauchst ist Dein Programm buggy, so einfach ist das. [..] linux/fs.h war hier nur ein beliebiges Beispiel für Header aus /usr/src/linux/include/linux/*.h, die config.h verwenden. Solange sie config.h includen, sind sie IMHO für Userland-Programme unbrauchbar und haben dort deshalb nichts ebenfalls nichts verloren, es sei denn es gäbe eine Konvention, dass alle Userland-Programme ein config.h bereitzustellen hätten (was ich für absurd halte).
des Kernels mit der glibc2 zu bundeln, mit der die glibc2 übersetzt wurde, ist _NICHT_ ausreichend, sondern bedarf weiterer Massnahmen (==Änderungen an den Kernelheadern). Die Aussage "Es müssen die Kernelheader mit der die glibc übersetzt wurde in die glibc-Header kopiert werden" ist somit schlichtweg falsch.
Nein, Dein Programm ist buggy. Das ist nicht der Punkt. Welchen Sinn machen Header unter /usr/include/linux, die Kernel-Config-Header erwarten (insb. config.h)?
Damit eng verwandt: gcc -I/usr/src/linux/include -o file.o -c file.c (Wird in den Makefiles einiger externer Modulen verwendet). Fehlt ein Header in /usr/src/linux/include, wird der aus /usr/include verwendet. Fehlt /usr/src/linux/include völlig, z.B. weil keine Kernelquellen installiert sind, und wird ein externes Kernelmodul übersetzt, passiert dann alles mögliche. Bis hin, dass Module mit völlig falschen Symbolen, scheinbar fehlerfrei kompiliert werden (Würde mich nicht überraschen, wenn etliche der NVidia-Probleme genau darauf zurückzuführen wären. Der gestrige Thread zum Thema NVidia + 2.4.2 riecht förmlich danach.)
Sorry, aber das ist nonsens. Wenn die Module richtig programmiert sind brechen sie ab, wenn kein /usr/src/linux existiert, ansonsten sind sie buggy und gehören gefixt. Dann sind NVidia's Makefiles offensichtlich buggy.
Deren Makefiles checken, ob /lib/modules/<version>/build/include vorhanden ist und schalten auf -I /usr/src/linux/include um, falls nicht. D.h. während der Kompilation wird implizit -I /usr/include verwendet, somit die Header aus /usr/include/linux anstatt der Kernelheader aufgegriffen (-nostdinc und -isystem werden nicht verwendet). Liegen dort die Kopien der Header eines konfigurierten Kernels, der nicht mit dem verwendeten Kernel übereinstimmt, geht es dahin.
=> D.h. aus meiner Sicht verlagert ein Verschieben der Kernelheader die Probleme nur, löst das Problem aber nicht wirklich, da nach wie vor genügend Raum für Inkonsistenzen zw. glibc und kernel bleiben.
Nein, nur buggy Programme fallen auf die Nase. Userland-Programme dürfen keine Kernel-Header includen, so einfach ist das. Da sind sich alle einig. Richtig, auch ich stimme dem ohne Einschränkung zu.
Insbesondere sehe ich nicht, wie das z.B. die vor einiger Zeit aufgetretenen scsi/sg.h-Inkompatibilitäten (Vgl. Documentation/scsi-generic.txt) u.ä. behoben oder gar vermieden hätte.
Gar nicht, weil diese Programme nur mit einem speziellen Kernel liefen und, sobald ich den ausgetauscht habe, auch nicht mehr gingen. Das beste Beispiel für ein broken Interface und der beste Grund dafür, niemals Kernel-spezische Header Dateien zu nehmen, sondern generische Wrapper, die mit allen Kernel laufen. Genau das wollte ich hören :).
IIRC, war die Vermeidung der Inkonsistenzen zwischen Kernel und glibc ursprünglich mal die Motivation ehemalige Kernelheader in die glibc aufzunehmen. Ralf