Sodele, mal wieder von einer der anderen Baustellen zurück.
Buildscripts v. 290520 sind online, lauffähig
HJS
Sodele, mal wieder von einer der anderen Baustellen zurück.
Buildscripts v. 290520 sind online, lauffähig
HJS
Und weiter im Text.
Hab etwas am Logging gebastelt.
Konsole 3 zeigt live den (Wesentlichen) Inhalt von install.log,
Konsole 4 zeigt live nur aufgetretene Fehler.
HJS
Nu geht auch, was oben steht
Allerdings sollte man sich auf den Consolen einloggen, sonst gehts nur manchmal
Ein Teil der neu hinzugefügten Packages klappt irgendwie noch nicht so recht.
Aber wenns einfach wär, könnts ja Jeder
Wenn die Scripte, die aktuelle Liste packen, wirds Zeit sich um die Dependencies des aktuellen VDR zu kümmern ... :):)
HJS
Langsam kommt Licht ins Dunkel.
Das Logging zerlegt noch manche Scripte, aber grundsätzlich funktionierts wieder.
Zumindest der Kernteil löppt durch, am Rest wird gearbeitet
HJS
Mit o.g. Umstrukturierung haben sich die Jungs wohl einen - wie sagt man so schön - _geritablen_ Kinken eingebaut.
Es sei denn, es ist Absicht, die libc des Hosts mittels "../configure --prefix=/usr [...]" im künftigen LFS abzulegen
Dachte, mein neuer Parser ist buggy, aber leider gibt das auch die Quelle her
Wenns der einzige Kinken ist ....
HJS
wo es auch sein soll, abba die Host-libc mit prefix /usr ?
Ich hätte - wie bis 9.1 immer gewesen - /tools als prefi erwartet
HJS
Langsam wirds heller.
Offensichtlich ist --prefix=/usr geplant.
War das Erste, was mir bei der Bauchlandung ins Auge fiel und schon eine massive Änderung.
Der hier bleibt mir schleierhaft:
case $(uname -m) in
i?86) ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3
;;
x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3
;;
esac
Von welchem PWD die Jungs hier mitten im Buildprozess ausgehen, bleibt mir verschlossen.
Führt zu einem toten Link namens lib64.
Da $LFS/bin erst in createdirectories angelegt wird, führt auch der spätere Veruch, die neu gebaute bash nach /bin/bash zu kopieren nebst link /bin/sh zu einer Datei bin auf $LFS und folglich reichlich Fehlern ...
Entweder bin ich blind, oder der Hinweis, das entsprechende Verzeichnis zu erstellen fehlt.
Naja, nix, was man nicht fixen kann ...
HJS
Mit 1.7.13.1 und Buildscripts vom 25.7. gibts nu wieder was lauffähiges.
Noch n paar Kinken, aber immerhin bootfähig mit mc
Was das o.e. Problem angeht:
Die Jungs wähnen sich in /mnt/lfs/sources, aber ohne /lib gibts nen toten Link und .so.3 --> so.2 klappt in eh nicht.
Das Problem korrigiert der Parser nun, solange es diese Problem bleibt.
Scheinbar ist die Umstellung noch sehr "development" , perl geht nicht, weil bzip2 noch nicht gebaut wurde, libstd-c++ geht nicht, weil flex noch nicht gebaut wurde ...
Diese beiden Probleme habe ich manuell korrigiert.
Nu schau ich mal, inwieweit ich solche Probs auch in Zukunft automatisiert abfangen kann.
Bisher war der Grund f das Versagen der Scripte stets zwischen meinen Ohren zu finden - biaher ist der Brich zwischen meinne Ohren allerdings weitestgehend schuldfrei
HJS
Sodele,
mit den Buildscripts v. 26.7. klappt auch der efiteil ( efivars,efibootmgr) wieder.
Neuer gcc, neuer patch
HJS
Mein renovierter Parser spuckt übrigens auch die ersten brauchbaren Scripte aus,
diesmal mit der Absicht möglichst viele Texte aus dem html zu übernehmen.
Nichtsdestrotrotz dauert es noch, bis ich damit bauen werde.
Sieht dann so in etwa aus (wird noch kleine Änderungen geben, weil ich einen mini-Uninstaller haben will).
#!/bin/bash
#*******************************************************************************
# 5.2. Binutils-2.34 - Pass 1
#*******************************************************************************
source ./addons;
# package: 'binutils-2.34'
# tarball: 'binutils-2.34.tar.xz'
chapter 5 2
prepare binutils-2.34.tar.xz
# ..............................................
# The Binutils package contains a linker, an assembler, and other tools for
# handling object files.
# ..............................................
# Approximate build time:
# 1 SBU
# Required disk space:
# 611 MB
#******** 5.2.1. Installation of Cross Binutils ********
#****** image: [Note] ******
#****** Note ******
# ..............................................
# Go back and re-read the notes in the section titled
# General Compilation Instructions
# . Understanding the notes labeled important can save you a lot of problems
# later.
# ..............................................
# ..............................................
# It is important that Binutils be the first package compiled because both Glibc
# and GCC perform various tests on the available linker and assembler to
# determine which of their own features to enable.
# ..............................................
# ..............................................
# The Binutils documentation recommends building Binutils in a dedicated build
# directory:
# ..............................................
mkdir -v build
cd build
#****** image: [Note] ******
#****** Note ******
# ..............................................
# In order for the SBU values listed in the rest of the book to be of any use,
# measure the time it takes to build this package from the configuration, up to
# and including the first install. To achieve this easily, wrap the commands in
# a
# time
# command like this:
# time { ./configure ... && make && make install; }
# .
# ..............................................
# ..............................................
# Now prepare Binutils for compilation:
# ..............................................
../configure --prefix=$LFS/tools \
--with-sysroot=$LFS \
--target=$LFS_TGT \
--disable-nls \
--disable-werror
# ..............................................
# The meaning of the configure options:
# ..............................................
# --prefix=$LFS/tools
# ..............................................
# This tells the configure script to prepare to install the binutils programs in
# the
# $LFS/tools
# directory.
# ..............................................
# --with-sysroot=$LFS
# ..............................................
# For cross compilation, this tells the build system to look in $LFS for the
# target system libraries as needed.
# ..............................................
# --target=$LFS_TGT
# ..............................................
# Because the machine description in the
# LFS_TGT
# variable is slightly different than the value returned by the
# config.guess
# script, this switch will tell the
# configure
# script to adjust binutil's build system for building a cross linker.
# ..............................................
# --disable-nls
# ..............................................
# This disables internationalization as i18n is not needed for the temporary
# tools.
# ..............................................
# --disable-werror
# ..............................................
# This prevents the build from stopping in the event that there are warnings
# from the host's compiler.
# ..............................................
# ..............................................
# Continue with compiling the package:
# ..............................................
make
# ..............................................
# Install the package:
# ..............................................
make install
# ..............................................
# Details on this package are located in
# Section 8.18.2, "Contents of Binutils."
# ..............................................
cleanup
Alles anzeigen
@#26:
'/mnt/lfs/lib64/ld-linux-x86-64.so.2' -> '../lib/ld-linux-x86-64.so.2'
'/mnt/lfs/lib64/ld-lsb-x86-64.so.3' -> '../lib/ld-linux-x86-64.so.2'
/mnt/lfs/lib64/../lib/ld-linux-x86-64.so.2 -> ld-2.31.so
Die Reihenfolge stimmt nicht, der Link müsste nach make install angelegt werden. Beim zweiten Anlauf läuft es durch.
Nö, danach lief alles einfach ohne Fehler durch, kein einziger weiterer Fehler. bzip2, flex, perl - alles gut.
Einige wenige Warnings, aber nichts Besorgnis erregendes.
Der Hauptteil der Arbeit war eher, die Sicherheitsabfragen in meinen 'drum-herum' Scripten zu fixen;
Ich frage jenach Kapitel (1-4,5-6,7-10) ab, on $LFS, $LFS_TGT, $LC_ALL gesetzt sind, ob als root gebaut wird oder als Std User,
ob das Script in chroot läuft und ob einige mounts aktiv sind. Hat mir sogar 1x den Poppes gerettet.
Reine Build Zeit plus anlegen 2x tar backups irgendwas bei 2.5h mit tools auf i7 mit 16GB Ram und SSD.
Da ginge sogar noch was.
Fertiges System wartet auf Einsatz - und nat. auf einige Teile von BLFS, FFMPEG, CUDA, Nvidia Treiber, ..
Könnte aber auch sein, dass ich aus Zeitgründen ne Abkürzung wähle und Jehova-Jehova die glibc auf dem System upgrade und die wichtigen Tools neu baue.
(nix für kleine Kinder..)
Merkwürden
ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
Verschieben der case [...] esac Sequenz führt immer noch zu nem toten Link lib64.
Hab meinen Workaround wieder eingesetzt.
Obiges erstellt einen Link namens lib64 , bei dir nicht ?
HJS
Die 1.7.17 bringt die Option, sowohl die abzuarbeitenden (addon)listen zu wählen als auch die packages aus der Liste.
Zu Debug Zwecken kann man nun die packages auswählen, nach deren Ausführung auf eine Eingabe gewartet wird ...
hjs
In der 1.7.17.4 hab ich den einen oder anderen zwischenzeitlich verbauten Kinken wieder gekickt
Nu startet er auch tatsächlich nach dem Basis-LFS die jeweiligen Packages aus den jeweils selektierten Listen.
Bis zur nächsten rund laufenden Version ( gilt noch nicht für X) lass ich die mal als "Pre" mit den Buildscripts vom 7.8. auf dem Index.
HJS
Nu ist die 1.7.21.4 mit buildscripts v. 16.8. die"stable".
Die scripts sind die letzte lfs Version vor der Umstellung. Diese Kombi führt zu einem lauffähigen Ergebnis, das die Basis für den künftigen Host ist.
Mit neueren buildscripts kann die 1.7.21.4 NICHT umgehen.
HJS
Die 1.7.23 ist online und kann mit den älteren und den neueren Scripts umgehen ...
HJS
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!