Archiv verlassen und diese Seite im Standarddesign anzeigen : nicht möglich 2.4.28 zu kompilieren
hi, ich versuche seit einigen tagen den "neuen" 2.4.28er kernel zu backen, allerdings war mir das bisher nicht möglich. ob nun beim 'make dep' oder beim 'make bzImage', es tritt immer folgender fehler auf:
root@bb-mu-slackware1:/usr/src/linux-2.4.28# make dep
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c
In file included from /usr/include/bits/posix1_lim.h:153,
from /usr/include/limits.h:144,
from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include/limits.h:122,
from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include/syslimits.h:7,
from /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include/limits.h:11,
from scripts/mkdep.c:35:
/usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory
scripts/mkdep.c: In function `add_path':
scripts/mkdep.c:221: error: `PATH_MAX' undeclared (first use in this function)
scripts/mkdep.c:221: error: (Each undeclared identifier is reported only once
scripts/mkdep.c:221: error: for each function it appears in.)
scripts/mkdep.c:221: warning: unused variable `resolved_path'
make: *** [scripts/mkdep] Error 1
getestet habe ich auf 2 verschiedenen systemen:
slackware 9.1 (updated to slackware current)
amd athlon k6-II 500mhz
und
slackware 10.0 (updated to slackware current)
pentium III 850mhz
beide configs sind im großteil gleich, unterschiede bestehen nur in den hardware-unterstützungen und ein paar wenigen kleinen dingen. wer möchte kann gerne mal versuchen diese config zu compilen (anhang).
meine eigenen recherchen blieben bisher ohne ergebnis.
kennt jemand diesen bug und hat ihn bereits behoben?
fällt jemandem eine lösung ein?
hat jemand eine erklärung?
ich bedanke mich schon mal im vorraus :).
Fehlende Dateien, weil nicht alle Pakete installiert?
Mein debian sagt mir, das die limits.h und die local_lim.h aus dem Paket
libc6-dev kommen.
nope, die dateien sind alle vorhanden.
ich hatte vergessen zu erwähnen, dass ich einen 2.4.27er kernel auf den selben systemen problemlos kompilieren kann.
Bist du sicher, dass du libc6-dev installiert hast? Sieht nämlich nicht so aus.
bei meinem slackware gibt es die limits.h in folgenden packeten:
gcc-3.3.4-i486-1 (installiert)
glibc-2.3.3-i486-2 (installiert)
in den kernel-headers
die local_lim.h befindet sich ebenfalls in glibc-2.3.3-i486-2.
wie gesagt, die packete sind installiert. die werden ja auch für die anderen kernels gebraucht, welche ich problemlos kompilieren kann.
bei meinem slackware gibt es die limits.h in folgenden packeten:
gcc-3.3.4-i486-1 (installiert)
glibc-2.3.3-i486-2 (installiert)
in den kernel-headers
die local_lim.h befindet sich ebenfalls in glibc-2.3.3-i486-2.
wie gesagt, die packete sind installiert. die werden ja auch für die anderen kernels gebraucht, welche ich problemlos kompilieren kann.
Aber irgendetwas stimmt trotzdem nicht.
Google mal nach "/usr/include/bits/local_lim.h:36:26: linux/limits.h:", da wirst du bestimmt fündig.
Diese Datei scheint es bei dir nämlich nicht zu geben.
Aber irgendetwas stimmt trotzdem nicht.
Google mal nach "/usr/include/bits/local_lim.h:36:26: linux/limits.h:", da wirst du bestimmt fündig.
Diese Datei scheint es bei dir nämlich nicht zu geben.
doch, die datei gibt es (die angeblich fehlenden dateien habe ich schon überprüft, bin ja nicht auf den kopf gefallen ;)).
Vielleicht fehlt dir ja nur ein Link (bzw. ist dieser falsch gesetzt?)
mit dem Namen Linux?
Schau doch mal nach, was es in /usr/src alles gibt?!?
Vielleicht fehlt dir ja nur ein Link (bzw. ist dieser falsch gesetzt?)
mit dem Namen Linux?
Schau doch mal nach, was es in /usr/src alles gibt?!?
ich habe jetzt herausgefunden, was das problem ist:
ich habe letzte woche die alten kernel-packages deinstalliert.
da ich die kernels sowieso direkt von kernel.org verwende, nach /usr/src entpacke und von dort aus compile, brauche ich die packages an sich ja wohl nicht (zumindest dachte ich das bisher).
mittlerweile habe ich entdeckt, dass ich diese ganzen compile-aktionen nur dann machen kann, wenn ich das packet 'kernel-headers' installiert habe.
irgendwie scheint dieses packet ein paar links zu setzen, welche durch ein reines
make dep
make clean
make bzImage
make modules
make modules_install
nicht entstehen.
weiß da jemand was genaueres?
also ich habe jetzt herausgefunden, was genau das problem war.
das package kernel-headers erstellt im ordner /usr/include/ 3 dinge:
softlink: asm -> asm-i386/
ordner: asm-i386/
ordner: linux/
in diese ordner (auf welche wohl make zugreift, wenn ein kernel kompiliert werden soll) werden die nötigen header-dateien kopiert, wenn man das package installiert. lädt man nun den kernel von hand runter fehlt diese "installation" natürlich. die entsprechenden dateien befinden sich zwar im kernel-verzeichnis, make greift aber wohl nicht direkt auf diese zu, sondern auf die bereits vorhandenen.
die lösung dafür ist einfach wie genial: einfach 3 softlinks setzen, die direkt auf die entsprechenden unterverzeichnisse in den kernel-sourcen zeigen.
z.b.:
asm -> asm-i386//
asm-i386 -> /usr/src/linux/include/asm-i386//
linux -> /usr/src/linux/include/linux//
einen dank an alle, die mir geholfen haben :).
derguteweka
15.12.04, 14:13
Moin,
also ich habe jetzt herausgefunden, was genau das problem war.
das package kernel-headers erstellt im ordner /usr/include/ 3 dinge:
softlink: asm -> asm-i386/
ordner: asm-i386/
ordner: linux/
Jepp, so isses. Den link kann man noch mit einem "make symlinks" erstellen, davor gibts noch "make include/linux/version.h"; die ganzen Header darf man dann mittels cp an die richtigen Stellen schieben.
Gruss
WK
Moin,
Jepp, so isses. Den link kann man noch mit einem "make symlinks" erstellen, davor gibts noch "make include/linux/version.h"; die ganzen Header darf man dann mittels cp an die richtigen Stellen schieben.
Gruss
WK
gut zu wissen.
ist es denn überhaupt notwendig die dinger dahin zu verschieben? es reicht doch, wenn ich da links direkt in die sources setze, denn da sind die dinger ja drin. so funzt es jedenfalls *g*.
derguteweka
15.12.04, 15:20
Moin,
gut zu wissen.
ist es denn überhaupt notwendig die dinger dahin zu verschieben? es reicht doch, wenn ich da links direkt in die sources setze, denn da sind die dinger ja drin. so funzt es jedenfalls *g*.
Oha, ich glaub' das ist ein wunder Punkt; ich zitier' mal aus dem LFS-Book(5.0), die wiederum ziteren Linus T.:
Why we copy the kernel headers and don't symlink them
In the past it was common practice to symlink the /usr/include/{linux,asm} directories to /usr/src/linux/include/{linux,asm}. This was a bad practice, as the following extract from a post by Linus Torvalds to the Linux Kernel Mailing List points out:
I would suggest that people who compile new kernels should:
- not have a single symbolic link in sight (except the one that the
kernel build itself sets up, namely the "linux/include/asm" symlink
that is only used for the internal kernel compile itself)
And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven't run a 2.2.13 kernel in a _loong_
time. But those headers were what Glibc was compiled against, so those
headers are what matches the library object files.
And this is actually what has been the suggested environment for at
least the last five years. I don't know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into "/usr/src/linux" even though that hasn't been
true in a _loong_ time.
The essential part is where Linus states that the header files should be the ones which Glibc was compiled against. These are the headers that should be used when you later compile other packages, as they are the ones that match the object-code library files. By copying the headers, we ensure that they remain available if later you upgrade your kernel.
Note, by the way, that it is perfectly all right to have the kernel sources in /usr/src/linux, as long as you don't have the /usr/include/{linux,asm} symlinks.
Gruss
WK
und was, wenn man seine glibc updated?
*dennoch merk und das alte package wieder installier*
danke dir :).
derguteweka
16.12.04, 12:17
Moin,
und was, wenn man seine glibc updated?
Das sollte man eigentlich nur dann tun, wenn man weiss was man da tut (und wenn mans genau weiss, was man da tut, dann tut mans wahrscheinlich doch nicht :) )- Will sagen; hier gabs schon den ein oder anderen Thread von Leuten, die sich ihren Rechner (bevorzugt root-server) mit einem glibc update schoen zerlegt haben...
Gruss
WK
Moin,
Das sollte man eigentlich nur dann tun, wenn man weiss was man da tut (und wenn mans genau weiss, was man da tut, dann tut mans wahrscheinlich doch nicht :) )- Will sagen; hier gabs schon den ein oder anderen Thread von Leuten, die sich ihren Rechner (bevorzugt root-server) mit einem glibc update schoen zerlegt haben...
Gruss
WK
ich weiß schon, was ich tue :).
bevor ich solche updates auf meinem/meinen servern mache, teste ich das selbstverständlich vorher auf "unwichtigen" rechnern, ob das update durchführbar ist. selbst wenn nicht, hab ich dank tagfiles und backups mit entsprechenden eigenen wiederherstellungsscripts mein system innerhalb einer halben stunde wieder. außerdem hab ich für diesen fall immer noch einen reserve-server auf lager.
naja, genug der ot-angeberei ;D.
vielen dank an alle helfer.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.