Hallo Waldemar, On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:
From the keyboard of Dieter, [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.
Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine.
Da nicht. Aber sehr wohl in /usr/include/linux und /usr/include/asm. Und bei mir ist, seit 2.2.10 (aber ich hab's seit 2.0.35 so gehalten) ist (rechte/datum gekuerzt) # ls -alF /usr/include/linux /usr/include/asm /usr/src/linux /usr/include/asm -> ../src/linux/include/asm/ /usr/include/linux -> ../src/linux/include/linux/ /usr/src/linux -> linux-2.4.16/ (bzw. /usr/src/linux jew. ein link auf den dann "hauptsaechlich" verwendeten kernel... # ls -alF /boot/bzImage* /boot/vm* /boot/*/bzImage* /boot/*/vm* \ 2>/dev/null | wc -l 29
Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC.
Mag sein. Aber ich wuerde Linus da widersprechen. Warum? Szenario: Schritt 1: libc-foo wird gegen kernel-2.2.x kompiliert, und verwendet also das kernel-api-2.2.x. Soweit, so gut, keine Diskussion. Ob die Header dabei die vom Kernel sind, oder bei der libc "dabeiliegen" ist irrelevant. Schritt 2: Updates... a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. -> Was wenn "syscall x" verschwindet? Da helfen die ach so tollen header von kernel-api-2.2.x die bei der libc dabei waren auch nicht weiter... Abhilfe: Vielleicht gibt's in den kernel-2.4.x headern ein kompatibilitaets-api Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} Das (veraltete) kernel-api der libc zu verwenden, wenn der kernel das api nicht mehr unterstuetzt ist IMO eine "Bad Idea"[tm]. b) Update der libc auf Version bar Verwendet das api von kernel-<auchegal> Folgerung: wenn libc-bar auf dem api von kernel-2.4.x beruht, macht's "PENG" wenn man noch kernel-2.2 verwendet und ein in 2.2 nicht vorhandenere syscall aufgerufen wird. Abhilfe: Kernelupdate/libc downdate. Nichts was man gerne mal so eben machen wollte. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} damit solche Probleme (nicht vorhandene syscalls) wenigstens beim kompilieren schon erkannt werden, und nicht erst zur laufzeit. Das (zu neue) kernel-api der libc zu verwenden, wenn der kernel das api nicht unterstuetzt ist IMO eine "Bad Idea"[tm]. c) beides updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} da nun auch die libc das passende api verwendet d) nichts updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} siehe c). Fazit: Linus liegt IMO falsch. Ich verwende hier eine glibc-2.1.3 (gegen 2.2.10 kompiliert!) und Kernel 2.4.16 und kann mir beim besten Willen nicht vorstellen, dass ein verwenden des 2.2.10er Kernel-apis alles gut gehen wuerde. Andersrum hat Linus (und Alan und ...) gute Arbeit geleistet, und das Kernel-api (in Grenzen) abwaertskompatibel gestaltet bzw. von vorherein moegl. Erweiterungen eingeplant. Dafuer zolle ich den beteiligten auch grossen Respekt. Ich habe hier definitiv Apps laufen, die gegen die libc-2.1.3/kernel-2.2.10 + kernel-2.2.10 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.2.14 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.4.0-test1 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.4.0-test4 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.4.16 kompiliert wurden... Keine Probleme! /usr/src/linux war dabei jew. _immer_ ein link auf die jew. aktuelle Kernelversion. Ja, (u.a.) _dafuer_ zolle ich Linus Respekt. Auch "testhalber" gegen eine "glibc-2.2.x/kernel-2.2.x" bzw "glibc-2.2.x/kernel-2.4.0" kompilierte SW lief genauso gut/schlecht. IMO sollte die die libc also gegen die jew. auf dem System vorhandene kernelversion kompiliert werden. Alles andere ist (s. a-d) IMO Schwachfug. Und /usr/src/linux ein link auf die aktuell verwendete Kernelversion. Denn "diese API" wird ja zur Laufzeit dann auch konkret verwendet, s.o.... Da hilft einem ein $Uralter_Header_gegen_den_die_libc_kompiliert_ wurde genau garnicht weiter. Glaubst du, dass ne $libc < 2.1.x, die gegen kernel < 2.0.y kompiliert wurde, dass deren Header noch mit 2.5.x kompatibel sind? Eben. Wenn man ne Chance hat, dann mit den aktuellen Headern! Denn der tollste header taucht nix, wenn's keine SW gibt die's auch implementiert! Du kannst 1000endmal ein "foo()" im (alten) (kernel) heeader haben und evtl. dagegen sogar kompilieren, wenn der (aktuelle!!!) Kernel foo() aber nicht mehr hat, stehst du doch ein wenig "dumm da"...
Hmm, was nun? Das Posting finde ich auf die schnelle nicht und in der Kernel FAQ finde ich es nicht, entweder du glaubst mir oder suchts selber *g*
Tja. ;) Ich glaube, ich hab das schon irgendwo mal gelesen... Und, s.o. ich widerspreche Linus' Meinung. So sehr ich Linus, Alan et.al respektiere, aber vom verlinken vom /usr/src/linux auf die jew. aktuell verwendete Kernelversion (und somit auch /usr/include/{asm,linux}) wird mich das nicht abhalten... -dnh, wie erwaehnt, seit 2.0.35 dieses Schema konsequent verwendend ;) -- 9: GUI Ein Hintergrundbild und 12 Xterms (Kristian Köhntopp)