Ich baue lfs-7.5.
Wenn ich make mrproperin Kapitel laufe6.7, es sagt:
make: gcc: Befehl nicht gefunden
und beim Ausführen bash /tools/bin/gccheißt es:
bash: /tools/bin/gcc: keine solche Datei oder kein solches Verzeichnis
Dies ist das gleiche Problem wieHier. Sogar die von der Person, die die Frage gestellt hat, in den Kommentaren angegebenen Informationen sind dieselben wie meine.
Er sagt, er habe „dritter Durchgang" von gccinKapitel 5. Wenn dies der Fall wäre, hätte uns der Autor von LFS eindeutig angewiesen, 3 Durchgänge durchzuführen. Ich vermute, dass ich irgendwo einen subtilen Fehler mache, aber ich kann nicht herausfinden, wo.
Laut dem von den LFS-Autoren bereitgestellten Support bitten sie uns, das Ganze von Anfang an neu zu machen. Ich stimme ihnen zu, aber ohne zu wissen, wo der Fehler passiert sein könnte, werden wir denselben Fehler mit Sicherheit wieder machen (wie ich). Die Ausgabe der Person, die die Frage in der LFS-Supportfrage gestellt hat, stimmt mit meiner überein. Dies ist dieVerknüpfung.
Noch eine Frage zum selben ThemaHierhat keine Antworten gebracht.
Bitte helfen Sie.
Übrigens, als ich herausfand, dass es gccnicht mit den Bibliotheken in /tools/libLFS verknüpft war, habe ich manuell einen Simlink von libc.so.6dort /libund /lib64darunter erstellt /mnt/lfs, wo ich die LFS-Partition gemountet habe. Aber als ich make headers_checkin6.7(nach make mrproper) wurde bemängelt, dass es nicht gefunden wurde libz.so, und als ich in suchte /tools/lib, konnte ich es nicht finden.
Antwort1
Ich weiß nicht, ob die vorherige Antwort, die ich eingereicht habe,richtigoder nicht.
LFS-7.5Ich habe mich entschieden, in fortzufahren Linux Mint, wo der Benutzer lfsin der sudoersDatei vorhanden war. Nach AbschlussKapitel 5, ich habe wieder einen Fehler beiKapitel 6.7 make mrproper. Also habe ich alle Ordner unter $LFS„außer“ gelöscht $LFS/sourcesund von vorne begonnen.
Nachdem ich den zweiten Durchgang von abgeschlossen hatte gcc, überprüfte ich, ob die Bibliotheken von gccauf die darunter liegenden verwiesen oder nicht. Aber ich stellte fest, dass sie immer noch auf das Hostsystem $LFS/toolsverwiesen ./usr
Ich habe also vom ersten Durchgang an neu aufgebaut gccund dann war alles in Ordnung.
Führen Sie nach dem zweiten Durchgang gccFolgendes durch:
ldd
$LFS/tools/bin/$LFS_TGT-gcc
und wenn die resultierende Ausgabe auf zeigt /usr, wiederholen Sie den Vorgang ab dem 1. Durchgang gcc.
Zumindest ist dies die Methode, die ich verwendet habe, und unmittelbar nachdem ich den ersten Durchgang beim gcczweiten Mal wiederholt hatte, zeigte die Ausgabe des obigen Befehls auf $LFS/tools/lib.
Antwort2
Ich konnte make mrproperdie folgenden Befehle erfolgreich ausführen. Ich weiß nicht wirklich, ob dies wirklich die Lösung für das obige Problem ist. Hier ist sie jedenfalls:
Ich habe Ubuntu 14.04 verwendet undlfsuser, wie im LFS-7.5-Buch vorgeschlagen. Aber das Problem war, dass ich erst viel später beim Aufrufen der LFS-Partition bemerkte, chrootdass der lfs-Benutzer nicht imsudoersDatei.
Ubuntu hat den Benutzer nicht automatisch zumsudoersDatei, wahrscheinlich so von den Ubuntu-Leuten beabsichtigt. Das könnte der Grund sein, warum ich es unter Ubuntu nicht noch einmal versucht habe.
Ich war entmutigt und begann, LFS-7.5 auszuprobieren inLinux Mint 16und der Benutzer wurde automatisch hinzugefügt zumsudoersDatei und alles lief gut beiKapitel 6.7beim Bauen und InstallierenLinux-Header.
Antwort3
Ich hatte genau das gleiche Problem. Ich habe den von gcc verwendeten dynamischen Linker überprüft: readelf -l /tools/bin/gcc | grep interpreterund er war nicht/tools/lib64/ld-linux-x86-64.so.2Aber/lib64/ld-linux-x86-64.so.2. Also konnte gcc nicht ausgeführt werden, da diese Datei nicht existierte.
Das Problem kam vom Erstellungsschritt von gcc Pass2. Ich habe die Definition von CC, CXX, AR und RANLIB nicht in dieselbe Zeile wie den Konfigurationsbefehl gesetzt.
Ich rannte
CC=$LFS_TGT-gcc
CXX=$LFS_TGT-g++
AR=$LFS_TGT-ar
RANLIB=$LFS_TGT-ranlib
../configure --prefix=/tools ...
Anstatt
CC=$LFS_TGT-gcc \
CXX=$LFS_TGT-g++ \
AR=$LFS_TGT-ar \
RANLIB=$LFS_TGT-ranlib \
../configure --prefix=/tools ...
Dasselbe Problem könnte im Build-Schritt von binutils pass2 auftreten. Ich vermute, es ist ein Problem mit dem variablen Fokus.