Philipp Thomas wrote:
* Melchior FRANZ [Mon, 30 Apr 2001 10:23:06 +0200]:
Trotzdem aendert sich nichts daran, dass das Umsetzen des /usr/src/linux-Links nach Installation eines neuen Kernels, aber ohne Neucompilation der libc fuer diesen Kernel, einfach =falsch= ist, solange die libc auf /usr/src/linux linkt.
Hättest du es mal so ausdrücklich in der ersten Mail geschrieben, hätte ich dir nicht widersprochen ;-)
Und an Ralph:
Hallo Filipp :)
durch die Trennung wird die glibc *nicht* an den Kernel gekoppelt bzw. nicht mehr, als es jetzt schon der Fall ist. Da stimme ich Dir zu, strenggenommen ist das auch jetzt schon weitgehend der Fall (Ausnahme: Kernel-Config-Header, vgl. unten.).
Die Kernelseite interessiert für normalen Userspace-Code nur die glibc. Normale Anwendungsprogramme sollten niemals direkt Kernelheader einbinden. Also betrifft das Problem externe Module und sehr systemnahe Utilities. Aber e2fsprogs machen schon seit längerem vor, wie man sich davon unabhängig macht: indem sie eigene Kopien der Kernelheader mitbringen. :)
Und externe Module können immer noch "Können" ist das Stichwort [1].
'-I /usr/src/<linux-version>/include' verwenden, womit die aktuellen Kernelheader zuerst gefunden werden. Das führt nicht zu Problemen, da Module ja ausschliesslich Kernelheader verwenden dürfen. Ja, die Probleme, die dann entstehen, sind andere.
Die entscheidende Fragen wären, * wohin /usr/include/[linux|scsi|asm] und /usr/src/linux zeigen, bzw. was sie beinhalten. * wie die Config-Header (linux/config.h, linux/autoconf.h) unter /usr/include/[linux|..] behandelt werden 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 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. 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.) Ein weiteres Problem: Externe Kernelpatches und korrespondierende Userspace-Programme (Beispiel aus der Vergangenheit: ReiserFS). Hier wird es dann notwendig, Header mehrfach zu behandeln, sobald diese Kernelpatches auf Kernelheader zugreifen (z.B. fs.h) und Userspaceprogrammen neue Features zur Verfügung stellen. => 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. 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. Ralf [1] Alsa-0.5.10b verwendet an einer Stelle AC_CHECK_HEADERS(linux/fs.h), d.h. /usr/include/linux, an anderen Stellen /usr/src/linux/include.