Wo liegen bei suse.de neue Kernel ?
Moin, wo finde ich bei suse neue Kernel, als rpm ? Danke für schnelle Antwort, denn hätte gerne den 2.4.3! Gruss aus Alzey
Am Samstag, 28. April 2001 14:38 schrieben Sie:
Moin,
wo finde ich bei suse neue Kernel, als rpm ?
Danke für schnelle Antwort, denn hätte gerne den 2.4.3!
Gruss aus Alzey
HOi Alzey! Also ich glaube der aktuelle Kernel ist bei SuSE gar nicht als rpm zum Download verfügbar. Unter ftp://ftp.suse.com/pub/people/mantel/next/ liegen nur die aktellen Kernel als tar.gz-Archive. Du solltest aber einen Mirror benutzen, da der Server immer ziemlich überlastet ist. Ich kann ftp://ftp.join.uni-muenster.de/pub/linux/distributions/suse/ftp.suse.com/pub/people/mantel/next/ empfehlen. Ob und wo man den Kernel als rom finet ist mir nicht bekannt. Wie gesagt gibt es unter den angegeben Quellen nur tar.gz-Archive. Viel erfolg marbre (Marius Brehler)
Hi, On Sat, 28 Apr 2001, Andreas Kunz wrote:
wo finde ich bei suse neue Kernel, als rpm ?
Auf dem ftp server. /pub/suse_update/X.X/kernel/
Danke für schnelle Antwort, denn hätte gerne den 2.4.3!
Den gibt es nicht als rpm. SuSE macht nur rpm updates für kernel wenns schwerwiegende bugs gibt. Henne -- Hendrik Vogelsang aka Henne mailto: mickey@naturalbornkiller.de Ist es kalt hier drinn, oder bin ich das? Demolition Man # random sigs made with fortune
* Henne Vogelsang [Sat, 28 Apr 2001 15:19:20 +0200 (CEST)]:
wo finde ich bei suse neue Kernel, als rpm ?
Auf dem ftp server. /pub/suse_update/X.X/kernel/
Den symlink gibt es bald nicht mehr. Korrekt muss es heissen: /pub/suse/<architektur>/update/<version>/kernel sprich für 7.1-i386 /pub/suse/i386/update/7.1/kernel -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
On Son, 29 Apr 2001, Philipp Thomas wrote:
/pub/suse/<architektur>/update/<version>/kernel sprich für 7.1-i386 /pub/suse/i386/update/7.1/kernel
Soviel zu offiziellen teil... Die un-supported kernels finden sich auch hier: ftp.suse.com/pub/people/mantel/ Mit freundlichen Grüßen, -- Jörg Henner Fon: +49 (7 11) 2 85 19 05 LiHAS - Servicebuero Stuttgart Fax: +49 (7 11) 5 78 06 92 Adrian Reyer & Jörg Henner GbR Mail: lihas@lihas.de Linux, Netzwerke, Consulting & Support http://lihas.de/
* Joerg Henner [Sun, 29 Apr 2001 15:05:17 +0200]:
Die un-supported kernels finden sich auch hier:
ftp.suse.com/pub/people/mantel/
Das muss ich doch ein wenig korrigieren ;-) Dort liegt der jeweils aktuellste SuSE kernel, allerdings nur als tarball den man selber kompilieren muss, am Besten mittels 'make cloneconfig'. Ach ja, den Symlink /usr/src/linux-XXXXX -> /usr/src/linux muss man selber noch setzen. Das erübrigt sich erst mit der 7.2, denn dort wird die glibc eine eigene Kopie der Kernelheader mit sich bringen. -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
* Philipp Thomas -- Sunday 29 April 2001 15:23:
Ach ja, den Symlink /usr/src/linux-XXXXX -> /usr/src/linux muss man selber noch setzen.
Ausser, man will's richtig machen. Dann setzt man den Link natuerlich nicht. Siehe dazu das Kernel README: Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be. m. ;-)
* Melchior FRANZ [Sun, 29 Apr 2001 15:49:37 +0200]:
* Philipp Thomas -- Sunday 29 April 2001 15:23:
Ach ja, den Symlink /usr/src/linux-XXXXX -> /usr/src/linux muss man selber noch setzen.
Ausser, man will's richtig machen. Dann setzt man den Link natuerlich nicht.
Siehe dazu das Kernel README:
Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be.
Falsch! Bis einschliesslich SuSE Linux 7.1 kommen die Header mit dem Kernel, entweder Paket lx_include (nur Kernelheader) oder eben lx_suse (kompletter Kernel). Das heisst, bis einschliesslich 7.1 *muss* der Symlink gesetzt werden. Erst mit der 7.2 wird sich das ändern. Glaube mir, ich *weiss* wovon ich rede und folge nicht nur READMEs ;-) -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
* Philipp Thomas -- Monday 30 April 2001 02:33:
* Melchior FRANZ [Sun, 29 Apr 2001 15:49:37 +0200]:
Ausser, man will's richtig machen. Dann setzt man den Link natuerlich nicht.
Siehe dazu das Kernel README: [...] Falsch! Bis einschliesslich SuSE Linux 7.1 kommen die Header mit dem Kernel, entweder Paket lx_include (nur Kernelheader) oder eben lx_suse (kompletter Kernel). Das heisst, bis einschliesslich 7.1 *muss* der Symlink gesetzt werden. Erst mit der 7.2 wird sich das ändern.
Glaube mir, ich *weiss* wovon ich rede und folge nicht nur READMEs ;-)
Nein! Natuerlich muss der Link in der =Distribution= derzeit auf die Sourcen des Kernels gesetzt werden, gegen den die libc gelinkt wurde. Und das tut Ihr ja auch. Aber dann darf der Link nicht mehr umgesetzt werden, nur weil man einen neuen Kernel installiert. Das ist erst wieder zu tun, wenn man auch die libc neu kompiliert. Da hat das README schon recht! Wenn mit SuSE 7.2 wirklich endlich Ulrich DREPPERS[1] Fehler behoben wird, und dieser unselige Link von /usr/include/linux auf /usr/src/linux/include/linux endlich der Vergangenheit angehoert, dann gibt's derlei Probleme natuerlich nicht mehr. m. PS: Glaube mir, ich weiss =auch= wovon ich rede. ;-) [1] libc Entwickler und Opponent Linus TORVALDS' in dieser Frage.
Melchior FRANZ wrote:
* Philipp Thomas -- Monday 30 April 2001 02:33:
* Melchior FRANZ [Sun, 29 Apr 2001 15:49:37 +0200]:
Ausser, man will's richtig machen. Dann setzt man den Link natuerlich nicht.
Siehe dazu das Kernel README: [...] Falsch! Bis einschliesslich SuSE Linux 7.1 kommen die Header mit dem Kernel, entweder Paket lx_include (nur Kernelheader) oder eben lx_suse (kompletter Kernel). Das heisst, bis einschliesslich 7.1 *muss* der Symlink gesetzt werden. Erst mit der 7.2 wird sich das ändern.
Wovon ich nicht sehr viel halte :)
Glaube mir, ich *weiss* wovon ich rede und folge nicht nur READMEs ;-)
Nein! Natuerlich muss der Link in der =Distribution= derzeit auf die Sourcen des Kernels gesetzt werden, gegen den die libc gelinkt wurde. Und das tut Ihr ja auch. Aber dann darf der Link nicht mehr umgesetzt werden, nur weil man einen neuen Kernel installiert. Das ist erst wieder zu tun, wenn man auch die libc neu kompiliert. Da hat das README schon recht! Nein.
Das Entscheidende ist die Kompatibilität/Konsistenz der zwischen glibc und Kernel geteilten Header. Ob diese auf Kernel oder glibc-Seite liegen, ist von zweitrangiger Bedeutung. Der wesentliche Vorteil diese Header in die glibc aufzunehmen, besteht darin, dass User dann nicht mehr vergessen können die betroffenen Header zu installieren, d.h. die momentan in Folge nicht vorhandener Header auftretenden Kompilierungsprobleme bei nicht vorhandenen Kernelheadern bei Userspace-Programmen treten dann nicht mehr auf.
Wenn mit SuSE 7.2 wirklich endlich Ulrich DREPPERS[1] Fehler behoben wird, und dieser unselige Link von /usr/include/linux auf /usr/src/linux/include/linux endlich der Vergangenheit angehoert, dann gibt's derlei Probleme natuerlich nicht mehr. Glaube mir, diese Probleme wird es auch in Zukunft geben - Nur äussern sie sich dann Anders.
Z.B.: * Viele Kernel-Module ausserhalb des Kernels werden schwerer zu übersetzen sein (Viele greifen direkt auf /usr/include/linux zu). * Wo liegt/Wem gehört linux/autoconf.h (Ist Kernel-Konfig-abhängig und wird von Treiber-Modulen benötigt)? * Werden die betroffenen Datenstrukturen geändert, treten die gleichen Probleme wie bisher auf. * Packaging-Problem: Diese Header sind Bestandteil der Kernelquellen, d.h. glibc-binaries werden in Zukunft mit der Kernelversion gekoppelt werden müssen (Strenggenommen, war dies bisher auch schon der Fall, wirkte sich aber nur selten aus). Da diese Punkte sehr systemnah liegen, ändert sich durch Verschieben der Header auf systemnaher Ebene nahezu nichts, ehe im Gegenteil. Ich bin mir nahezu sicher, dass in Zukunft die Problemem, die gelegentliche Kernel-/Treiber-Übersetzer haben werden dadurch ehe zunehmen werden.
PS: Glaube mir, ich weiss =auch= wovon ich rede. ;-) Ich auch ;-)
Nachdem sich selbst Drepper und Torwalds nicht einigen können, werden auch wir das hier nicht lösen können. Gruss Ralf
* Ralf Corsepius -- Monday 30 April 2001 09:20:
Nachdem sich selbst Drepper und Torwalds nicht einigen können, werden auch wir das hier nicht lösen können.
Das stimmt. (Torvalds ist hier eindeutig im Recht und es verwundert schon etwas, dass Drepper keine Einsicht zeigt/gezeigt hat!) 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. Daran aendert weder die Beteuerung etwas, dass man schon wisse wovon man rede, noch die Tatsache, dass es bei nicht allzuweit auseinanderliegenden Kernelversionen wahrscheinlich keine Probleme ergibt. Ich beschreibe hier auch nicht =meine= Sicht der Dinge, sondern die von Linus. Und =wenn= einer wirklich weiss, wovon er (in Bezug auf Linux) spricht, dann ist es viel eher Linus als irgendjemand auf dieser Liste. m. :-)
Am Montag, 30. April 2001 10:23 schrieb Melchior FRANZ:
* Ralf Corsepius -- Monday 30 April 2001 09:20:
Nachdem sich selbst Drepper und Torwalds nicht einigen können, werden auch wir das hier nicht lösen können.
Das stimmt. (Torvalds ist hier eindeutig im Recht und es verwundert schon etwas, dass Drepper keine Einsicht zeigt/gezeigt hat!) 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. Daran aendert weder die Beteuerung etwas, dass man schon wisse wovon man rede, noch die Tatsache, dass es bei nicht allzuweit auseinanderliegenden Kernelversionen wahrscheinlich keine Probleme ergibt. Ich beschreibe hier auch nicht =meine= Sicht der Dinge, [...]
Da ich mir ja hier und da auch mal eigene Kernels baue hab ich da mal eine Frage dazu: Was ist den unter "nicht allzuweit auseinanderliegenden Kernelversionen" zu verstehen? z.B. 2.2.18 nach 2.4.4, oder schon bei 2.4.2 nach 2.4.4? Ich habe mal gehört, ein selber bauen der lib soll ja nicht gerade einfach sein... -- mfg, Peter Küchler Planungsverband Frankfurt Region Rhein Main Systemadministrator
* 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: durch die Trennung wird die glibc *nicht* an den Kernel gekoppelt bzw. nicht mehr, als es jetzt schon der Fall ist. 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 '-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. -- Penguins to save the dinosaurs -- Handelsblatt on Linux for S/390
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.
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, die andern beiden Verzeichnisse haben Dich nicht zu interessieren. Wenn Du sie doch für ein Userland-Programm brauchst machst Du etwas falsch.
* wie die Config-Header (linux/config.h, linux/autoconf.h) unter /usr/include/[linux|..] behandelt werden
Die haben da gar nichts verloren. 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.
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. Schau Dir z.B. mount an, wie einfach es auch korrekt geht. Und das sogar noch für Filesysteme, die Du nur mit der Benutzung von linux/fs.h heute gar nicht mehr mounten könntest.
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.
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.
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.
Nochmal: Userland-Programme dürfen keine Kernel-Headers includen.
=> 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.
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. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
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
* Philipp Thomas -- Monday 30 April 2001 22:48:
* 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 ;-)
Tja, manchmal sind meine Formulierungen einfach Sch**sse ... :-) m. -- while (!asleep()) sheep++;
On Mon, 30 Apr 2001, Philipp Thomas wrote:
Und externe Module können immer noch '-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.
Ist für sowas nicht eigentlich der Link /lib/modules/x.y.z/build gedacht? (Das setzt natürlich voraus, daß der Link auf das *reale* Build- Directory zeigt und nicht auf /usr/src/linux wie die aktuellen SuSE-Kernel... :-() Martin
Moin, Am Sonntag, 29. April 2001 15:23 schrieb Philipp Thomas:
* Joerg Henner [Sun, 29 Apr 2001 15:05:17 +0200]:
Ach ja, den Symlink /usr/src/linux-XXXXX -> /usr/src/linux muss man selber noch setzen. Das erübrigt sich erst mit der 7.2, denn dort wird die glibc eine eigene Kopie der Kernelheader mit sich bringen.
Habe mich heute dazu entschlossen mir jetzt doch mal nen Kernel zu basteln :-) Nun habe ich mal in der Suse-Hilfe nach Symlink gesucht, wie setze ich diesen SYMLINK ??? Für eine schnelle Antwort wäre ich dankbar, weil will jetzt mal das bzImage anschmeissen. Gruss aus Alzey
Am Freitag, 4. Mai 2001 11:37 schrieb Andreas Kunz:
Moin,
Am Sonntag, 29. April 2001 15:23 schrieb Philipp Thomas:
* Joerg Henner [Sun, 29 Apr 2001 15:05:17 +0200]:
Ach ja, den Symlink /usr/src/linux-XXXXX -> /usr/src/linux muss man selber noch setzen. Das erübrigt sich erst mit der 7.2, denn dort wird die glibc eine eigene Kopie der Kernelheader mit sich bringen.
Habe mich heute dazu entschlossen mir jetzt doch mal nen Kernel zu basteln :-)
Nun habe ich mal in der Suse-Hilfe nach Symlink gesucht, wie setze ich diesen SYMLINK ???
Für eine schnelle Antwort wäre ich dankbar, weil will jetzt mal das bzImage anschmeissen.
Gruss aus Alzey
ln -s /usr/src/linux-2.4.4 /usr/src/linux vorrausgesetzt, Dein neuer Kernel ist im Verzeichnis /usr/src/linux-2.4.4 Gruss aus Niederbayern Herbert -- Mein PGP-Schlüssel befindet sich auf http://wwwkeys.de.pgp.net Fingerprint: 3553 0C44 431B 9DED FAF8 46AD FFE5 BF45 D88F 7EFD
Moin! Am Freitag, 4. Mai 2001 11:50 schrieb Herbert Renkewitz:
Am Freitag, 4. Mai 2001 11:37 schrieb Andreas Kunz:
Moin,
Am Sonntag, 29. April 2001 15:23 schrieb Philipp Thomas:
* Joerg Henner [Sun, 29 Apr 2001 15:05:17 +0200]:
Ach ja, den Symlink /usr/src/linux-XXXXX -> /usr/src/linux muss man selber noch setzen. Das erübrigt sich erst mit der 7.2, denn dort wird die glibc eine eigene Kopie der Kernelheader mit sich bringen.
Nun habe ich mal in der Suse-Hilfe nach Symlink gesucht, wie setze ich diesen SYMLINK ???
ln -s /usr/src/linux-2.4.4 /usr/src/linux
Habe es angepasst , da ich jetzt gerade mit dem 2.4.3 rumspiele. Klappt aber alles nicht so, wie ich es mir vorgestellt habe :-( Nochmal für kleine DAU´s wie mich. 1.) Neue Kernelquellen besorgen. 2.) Auspacken und in ein Verzeichnis unter /usr/src/ kopieren 3.) Aufruf von make oldconfig, anschliessend Make menueconfig und noch die neuen Kernenfeatures kontrollieren und anpassen. 4.) SYMLINK gesetzt (ln -s /usr/src/linux-2.4.3 /usr/src/linux) 5.) make dep 6.) make bzImage und dann kommt bei mir folgendes: root@andy:/usr/src/linux-2.4.3 > make bzImage gcc -D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall -Wstrict-prototypes -O2 -f omit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -marc h=i686 -DUTS_MACHINE='"i386"' -c -o init/version.o init/version.c make CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall -Wstrict-prototyp es -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundar y=2 -march=i686 " -C kernel make[1]: Entering directory `/usr/src/linux-2.4.3/kernel' make all_targets make[2]: Entering directory `/usr/src/linux-2.4.3/kernel' gcc -D__KERNEL__ -I/usr/src/linux-2.4.3/include -Wall -Wstrict-prototypes -O2 -f omit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -marc h=i686 -DEXPORT_SYMTAB -c ksyms.c In file included from /usr/src/linux-2.4.3/include/linux/modversions.h:97, from /usr/src/linux-2.4.3/include/linux/module.h:21, from ksyms.c:14: /usr/src/linux-2.4.3/include/linux/modules/i386_ksyms.ver:76: warning: `cpu_data ' redefined /usr/src/linux-2.4.3/include/asm/processor.h:78: warning: this is the location o f the previous definition /usr/src/linux-2.4.3/include/linux/modules/i386_ksyms.ver:80: warning: `smp_num_ cpus' redefined /usr/src/linux-2.4.3/include/linux/smp.h:80: warning: this is the location of th e previous definition /usr/src/linux-2.4.3/include/linux/modules/i386_ksyms.ver:82: warning: `cpu_onli ne_map' redefined /usr/src/linux-2.4.3/include/linux/smp.h:88: warning: this is the location of th e previous definition /usr/src/linux-2.4.3/include/linux/modules/i386_ksyms.ver:96: warning: `smp_call _function' redefined /usr/src/linux-2.4.3/include/linux/smp.h:87: warning: this is the location of th e previous definition In file included from /usr/src/linux-2.4.3/include/linux/modversions.h:121, from /usr/src/linux-2.4.3/include/linux/module.h:21, from ksyms.c:14: /usr/src/linux-2.4.3/include/linux/modules/ksyms.ver:506: warning: `del_timer_sy nc' redefined /usr/src/linux-2.4.3/include/linux/timer.h:34: warning: this is the location of the previous definition In file included from /usr/src/linux-2.4.3/include/linux/interrupt.h:45, from ksyms.c:21: /usr/src/linux-2.4.3/include/asm/hardirq.h:37: warning: `synchronize_irq' redefi ned /usr/src/linux-2.4.3/include/linux/modules/i386_ksyms.ver:84: warning: this is t he location of the previous definition In file included from ksyms.c:17: /usr/src/linux-2.4.3/include/linux/kernel_stat.h: In function `kstat_irqs': /usr/src/linux-2.4.3/include/linux/kernel_stat.h:48: `smp_num_cpus' undeclared ( first use in this function) /usr/src/linux-2.4.3/include/linux/kernel_stat.h:48: (Each undeclared identifier is reported only once /usr/src/linux-2.4.3/include/linux/kernel_stat.h:48: for each function it appear s in.) make[2]: *** [ksyms.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.3/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.3/kernel' make: *** [_dir_kernel] Error 2 Irgendwas scheint hier noch nicht zu stimmen, hat einer einen Plan ???? Gruss aus Alzey
participants (11)
-
Andreas Kunz -
Henne Vogelsang -
Herbert Renkewitz -
Joerg Henner -
Marius Brehler -
Martin Köhling -
Melchior FRANZ -
Peter Kuechler -
Philipp Thomas -
Ralf Corsepius -
Thorsten Kukuk