Hallo, On Sat, 02 Nov 2002, Maik Holtkamp wrote:
Am 02/11/01@23:08 schrieb David Haller:
On Fri, 01 Nov 2002, Jan Boy Dietrich wrote:
/usr/include/bits/local_lim.h:36:26: linux/limits.h: Datei oder Verzeichnis nicht gefunden Was sagt denn ein 'ls -l /usr/include/linux'? Existierts? Und ist's ein Verzeichnis oder ein symlink auf ../src/linux/include/linux?
Soll das so sein?
Jein. (cue IIRC z.B. Philipp, Thorsten und mich, s.u. ;)...
Ich dachte in /usr/include sollten die header des kernels liegen, gegen die die glibc gelinkt wurde, egal welcher kernel da grad läuft.
Jein. Da gibt's unterschiedliche Meinungen dazu. Und ich pflege nunmal eine von den glibc-Maintainern (und Linus IIRC?) oder andersrum(?) abweichende Meinung. Kurzfassung (die lange solltest du im Archiv finden koennen): Fuer beide Varianten a) /usr/include/linux enthaelt header gegen die die glibc gelinkt wurde b) /usr/include/linux ist symlink auf die includes des aktuell verwendeten Kernels finden sich Argumente pro und contra (wer jetzt welche Meinung vertritt ist erstmal irrelevant und interessiert mich hier auch nicht weiter, Linus vertritt IIRC Variante a). Oben hatte ich _explizit_ das _ODER_ verwendet, um diese Diskussion nicht nochmal zu entfachen... BEIDE Variante funktionieren (wenn auch nur eingeschraenkt). Ich praktiziere und vertrete Meinung "b", da nach meinem Verstaendnis so evtl. Konflikte zwischen Kernel und libc frueher (beim kompilieren/linken) auftreten (und nicht erst zur Laufzeit, was IMO bei Variante a der Fall sein koennte). Im Endeffekt geht's in beiden Varianten um die Rueckwaerts- kompatibilitaet von Kernel und libc, und darum, wann's im Falle der Inkompatibilitaet dann eben "*PENG*" (bzw. "Oops") macht (und da seh ich Var. "b" eben im Vorteil). Naeheres solltest du im Archiv finden... Wegen mir koennen wir das Thema, falls z.B. Philipp auch in der Laune ist, aber auch nochmal durchkauen, 's ist IIRC ja auch nur schon nen Jahr her oder so... ;) -dnh -- 177: Mainframe-Admin Arbeitsschutzschuhe (Holger Spielmann)