Problem beim Erstellen einer LFS-Toolchain

Hallo
mache wohl noch viele Anfängerfehler. Nach mehrfachen Versuchen hier meine vorgehensweise.
LFS neu gestartet
Konsole aufgerufen
export LFS=/mnt/$LFS
mount /dev/hdc1 $LFS
cd $LFS
ls
lost+found sources tools
df -h
396mb von 5,1 gb belegt
Habe nochmals von vorn angefangen und wieder der gleiche Fehler. Zu wenig Speicherplatz. Beim entpacken der gcc-4.0.3 tritt der Fehler schon auf.
Gruß Ralf
 
Uebrigens, gestern Abend war mir noch was eingefallen was mir an der 6.2 aufgefallen war, das hab ich heute Morgen nochmal gecheckt und es wurde bestaetigt.
Das ist uebrigens eine Sache die ich an der 6.2 nicht mag und nicht wirklich nachvollziehen kann, es werden naemlich 2 verschiedene Kernel genutzt, 2.6.12 fuer die Header und 2.6.16.27 fuer den Betrieb.
 
Das ist uebrigens eine Sache die ich an der 6.2 nicht mag und nicht wirklich nachvollziehen kann, es werden naemlich 2 verschiedene Kernel genutzt, 2.6.12 fuer die Header und 2.6.16.27 fuer den Betrieb.
Die Gründe dafür, stehen z.B. hier mit im Text:
http://oss.erdfunkstelle.de/lfs-de/6.2/online/chapter05/linux-libc-headers.html

In der 6.1 waren es auch die 2.6.11.2er linux-libc-header und ein 2.6.11.12er Kernel.

Erst seit dem der 2.6.19er Kernel im LFS-Development-Zweig verwendet wird, werden wieder die "originalen" Kernel-header verwendet.

Bei mir sind übrigens immernoch die 2.6.12er Linux-Libc-Header installiert, laufen tut mein System momentan problemlos unter einem 2.6.20.6er Kernel.

Schönen Tag noch, man liest sich. :)
Euer Jens Ornot alias Webstar
 
Ich hab 6.1.1 gebaut, und meine mich zu erinnern, dass dort Kernel-Header und laufender Kernel gleich waren (auch wenn ich beide schon bei der Installation durch aktuellere Versionen ersetzt habe, wie auch grosse Teile der sonstigen Software ;) ). Kann mich aber auch irren.
Auf jeden Fall hab ich vor einiger Zeit meine Kernel-Header auf 2.6.19.irgendwas aktualisiert da QEmu mit den alten Headern absolut nicht kompilieren wollte.
Aktuell laufen hab ich 2.6.20.4.
 
Ich hab 6.1.1 gebaut, und meine mich zu erinnern, dass dort Kernel-Header und laufender Kernel gleich waren (auch wenn ich beide schon bei der Installation durch aktuellere Versionen ersetzt habe, wie auch grosse Teile der sonstigen Software ;) ). Kann mich aber auch irren.
Auf jeden Fall hab ich vor einiger Zeit meine Kernel-Header auf 2.6.19.irgendwas aktualisiert da QEmu mit den alten Headern absolut nicht kompilieren wollte.
Aktuell laufen hab ich 2.6.20.4.
Vielleicht sollten wir einen separaten Thread zu dieser Problematik eröffnen?
Da Ralph41 ja ein anderes Problem zu bewältigen hat.

Ausserdem fände ich es besser, wenn Ralph den Threadtitel in einen treffenderen umbenennt.
Wie wäre es mit: "Problem beim Erstellen einer LFS-Toolchain"

Denn was Ralph41 bis jetzt geschrieben hat, lässt nicht auf einen Fehler beim GCC-Build schliessen,
sonderen auf einen generellen Fehler bei der Toolchain-Konfiguration hindeuten.
Dort müssen einige wichtige Variablen gesetzt bzw. Vorgehensweisen eingehalten werden.

Schönen Tag noch, man liest sich. :)
Euer Jens Ornot alias Webstar
 
Ausserdem fände ich es besser, wenn Ralph den Threadtitel in einen treffenderen umbenennt.
Wie wäre es mit: "Problem beim Erstellen einer LFS-Toolchain"
Ich bin mal so frei.

@Topicsplit: Ich denk nicht, dass das noch noetig ist, es wurde ja soweit alles zu diesem kleinen :offtopic:-Exkurs gesagt.

Um noch was zum Thema zu sagen:
Was gibt Dir denn df -h aus nachdem Du die Zielpartition gemountet hast?
 
Hallo,
Die Gründe dafür, stehen z.B. hier mit im Text:
http://oss.erdfunkstelle.de/lfs-de/6.2/online/chapter05/linux-libc-headers.html

In der 6.1 waren es auch die 2.6.11.2er linux-libc-header und ein 2.6.11.12er Kernel.

Erst seit dem der 2.6.19er Kernel im LFS-Development-Zweig verwendet wird, werden wieder die "originalen" Kernel-header verwendet.

Bei mir sind übrigens immernoch die 2.6.12er Linux-Libc-Header installiert, laufen tut mein System momentan problemlos unter einem 2.6.20.6er Kernel.

Also die linux-libc-header sind ja nicht die Original Kernel Header, sondern dienen zur Schnittstelle zwischen Userspace- Programmen und Kernelheader. Kernelcode darf ja gar nicht gegen die glibc gelinkt werden...
Und die Original Kernelheader (welche sich gewöhnlich im Verz. /usr/src/ befinden) sollten definitiv der Version des laufenden Kernel entsprechen. Alles weitere führt nur zu Inkonsistenzen beim Kompilieren von Treibern oder ähnlichem, denn /lib/modules/`uname -r`/build ist immer ein Link zu den Kernelheadern bzw Kernelsourcen des laufenden Kernels...

Gruß,
RedWing
 
Alles weitere führt nur zu Inkonsistenzen beim Kompilieren von Treibern oder ähnlichem, denn /lib/modules/`uname -r`/build ist immer ein Link zu den Kernelheadern bzw Kernelsourcen des laufenden Kernels...

Wobei dieser Link scheinbar davon beeinflusst wird wo man denn baut, oder aber wo die Daten wirklich liegen (das muesste ich pruefen).
Ich bau meine Kernel in der Regel unter /download/linux, welches ein Link auf das Source-Verzeichnis ist. /usr/src/linux ist wiederum ein Link auf /download/linux.
 
Hallo,
Dennis hat gesagt.:
Wobei dieser Link scheinbar davon beeinflusst wird wo man denn baut, oder aber wo die Daten wirklich liegen

Nicht nur scheinbar ;). /usr/src war nur ein Beispiel.
Die Tatsache das sich die Sourcen je nach Nutzer an unterschiedlichen Stellen befinden können, und bspw. ein zu kompilierender Treiber das kbuild Makefile finden muss, was sich im Kerneltree an oberster Stelle befindet, gibt dem "build- link" in /lib/modules/`uname -r`/ seine Daseinberechtigung. Wo der "build- Link" hinzeigt ist letztlich egal, solange er auf die Sourcen bzw Header des aktuell laufenden Kernels zeigt, das hängt natürlich davon ab an welcher Stelle du deinen Kernel baust.

Aber wir schweifen vom Thema ab :)

Gruß,
RedWing
 

Neue Beiträge

Zurück