The LFS editors recommend that the system CPU have at least four cores and that the system have at least 8 GB of memory. Older systems that do not meet these requirements will still work, but the time to build packages will be significantly longer than documented.
Your host system should have the following software with the
minimum versions indicated. This should not be an issue for most
modern Linux distributions. Also note that many distributions will
place software headers into separate packages, often in the form of
or <package-name>-devel. Be
sure to install those if your distribution provides them.
<package-name>-dev
Earlier versions of the listed software packages may work, but have not been tested.
Be aware that GCC newer (exclusively) than 15.2.0 or Binutils newer (exclusively) than 2.46.0 are not tested. Especially, a newer GCC is expected to be highly likely to break the build of this LFS release. Do not report such a breakage to the LFS editors. Try reading a newer release of the LFS book (if one exists), or using an older host distro, or downgrading GCC (if the host distro supports to do so), or reading the latest LFS development book (if it still does not support the GCC version on your host distro, wait for the editors to update the book for 2 or 4 weeks).
Bash-3.2 (/bin/sh should be a symbolic or hard link to bash)
Binutils-2.38 (Versions greater than 2.46.0 may not work as they have not been tested)
Bison-2.7 (/usr/bin/yacc should be a link to bison or a small script that executes bison)
Coreutils-8.1
Diffutils-2.8.1
Findutils-4.2.31
Gawk-4.0.1 (/usr/bin/awk should be a link to gawk)
GCC-12.2 including the C++ compiler, g++ (Versions greater than 15.2.0 may not work as they have not been tested). C and C++ standard libraries (with headers) must also be present so the C++ compiler can build hosted programs
Grep-2.5.1a
Gzip-1.3.12
Linux Kernel-5.19
The reason for the kernel version requirement is that we specify that version when building glibc in Chapter 5 and Chapter 8, and 5.19 is the oldest kernel release supported by Glibc for LoongArch.
If a Linux distribution on LoongArch provides a kernel older (exclusively) than 5.19, it indicates the distribution is using a preliminary draft of the ABI provided by the kernel for the userspace. The ABI had been revised for several times before it was finally integrated into Linux 5.19 and stablized, so those old kernel versions are incompatible with some critical packages those we will build (at least, glibc and GCC). Such an “old-world” distro (for example, Loongnix 20) cannot be used as a host distro for building LFS.
Do not attempt to update the kernel to 5.19 or later on an old-world distro because doing so will almost definitely cause a boot failure due to the ABI difference (i.e. the init process will likely crash very soon after startup). Use a “new-world” distro providing Linux 5.19 or newer instead.
Another source of the compatability issues is the boot protocol provided by the firmware. The UEFI specification for LoongArch had been also revised for several times, similar to the revisions of the kernel ABI for userspace. The GRUB and Linux kernel packages those we'll build for LFS are not compatible with the old firmware developed following the early drafts of the UEFI specifications. Those old firmware implementations are only reported to exist on the earliest models of the LoongArch hardware based on Loongson 3A5000 processors and Loongson 7A1000 bridge chips. If you have such a board, you may need to contact the vendor of your hardware to get a firmware update in order to boot LFS.
Some sources describe the boot protocol difference as a part of the “old-world” with “new-world” difference. We consider such a description misleading and confusing. In fact, the boot protocol difference is orthogonal with the difference of the kernel ABI for userspace. You may boot some “new-world” distros (for example, AOSC OS) on a firmware implementation providing the old boot protocol because the maintainers of those distros have custom modifications to the GRUB and Linux kernel for the old boot protocol support and build LFS fine, but then LFS will fail to boot there. Similarly, many “old-world” distros can also boot on newer firmware implementations following the stabilized UEFI specification. As the result, clearly distinguishing those two kinds of differences is important to avoid confusions like “my board has a [so called] new-world firmware and I've booted a distro [actually, old-world, perhaps just Loongnix 20] there fine, so the distro must be new-world but why does it fail to work as a host distro for building LFS?”
We require the host kernel to support UNIX 98 pseudo terminal
(PTY). It should be enabled on all desktop or server distros
shipping Linux 5.19 or a newer kernel. If you are building a
custom host kernel, ensure CONFIG_UNIX98_PTYS is set to y in the kernel configuration.
M4-1.4.10
Make-4.0
Patch-2.5.4
Perl-5.8.8
Python-3.4
Sed-4.1.5
Tar-1.22
Texinfo-5.0
Xz-5.0.0
Additionally, if you need to create a new ESP (EFI System Partition, read Section 2.5, “Creating a File System on the Partition” for details), dosfstools is needed.
Note that the symlinks mentioned above are required to build an LFS system using the instructions contained within this book. Symlinks that point to other software (such as dash, mawk, etc.) may work, but are not tested or supported by the LFS development team, and may require either deviation from the instructions or additional patches to some packages.
To see whether your host system has all the appropriate versions, and the ability to compile programs, run the following commands:
cat > version-check.sh << "EOF"
#!/bin/bash
# A script to list version numbers of critical development tools
# If you have tools installed in other directories, adjust PATH here AND
# in ~lfs/.bashrc (section 4.4) as well.
LC_ALL=C
PATH=/usr/bin:/bin
bail() { echo "FATAL: $1"; exit 1; }
grep --version > /dev/null 2> /dev/null || bail "grep does not work"
sed '' /dev/null || bail "sed does not work"
sort /dev/null || bail "sort does not work"
ver_check()
{
if ! type -p $2 &>/dev/null
then
echo "ERROR: Cannot find $2 ($1)"; return 1;
fi
v=$($2 --version 2>&1 | grep -E -o '[0-9]+\.[0-9\.]+[a-z]*' | head -n1)
if printf '%s\n' $3 $v | sort --version-sort --check &>/dev/null
then
printf "OK: %-9s %-6s >= $3\n" "$1" "$v"; return 0;
else
printf "ERROR: %-9s is TOO OLD ($3 or later required)\n" "$1";
return 1;
fi
}
ver_kernel()
{
kver=$(uname -r | grep -E -o '^[0-9\.]+')
if printf '%s\n' $1 $kver | sort --version-sort --check &>/dev/null
then
printf "OK: Linux Kernel $kver >= $1\n"; return 0;
else
printf "ERROR: Linux Kernel ($kver) is TOO OLD ($1 or later required)\n" "$kver";
return 1;
fi
}
# Coreutils first because --version-sort needs Coreutils >= 7.0
ver_check Coreutils sort 8.1 || bail "Coreutils too old, stop"
ver_check Bash bash 3.2
ver_check Binutils ld 2.38
ver_check Bison bison 2.7
ver_check Diffutils diff 2.8.1
ver_check Findutils find 4.2.31
ver_check Gawk gawk 4.0.1
ver_check GCC gcc 12.2
ver_check "GCC (C++)" g++ 12.2
ver_check Grep grep 2.5.1a
ver_check Gzip gzip 1.3.12
ver_check M4 m4 1.4.10
ver_check Make make 4.0
ver_check Patch patch 2.5.4
ver_check Perl perl 5.8.8
ver_check Python python3 3.4
ver_check Sed sed 4.1.5
ver_check Tar tar 1.22
ver_check Texinfo texi2any 5.0
ver_check Xz xz 5.0.0
ver_kernel 5.19
if mount | grep -q 'devpts on /dev/pts' && [ -e /dev/ptmx ]
then echo "OK: Linux Kernel supports UNIX 98 PTY";
else echo "ERROR: Linux Kernel does NOT support UNIX 98 PTY"; fi
alias_check() {
if $1 --version 2>&1 | grep -qi $2
then printf "OK: %-4s is $2\n" "$1";
else printf "ERROR: %-4s is NOT $2\n" "$1"; fi
}
echo "Aliases:"
alias_check awk GNU
alias_check yacc Bison
alias_check sh Bash
echo "Compiler check:"
if printf "int main(){}" | g++ -x c++ -
then echo "OK: g++ works";
else echo "ERROR: g++ does NOT work"; fi
rm -f a.out
if [ "$(nproc)" = "" ]; then
echo "ERROR: nproc is not available or it produces empty output"
else
echo "OK: nproc reports $(nproc) logical cores are available"
fi
EOF
bash version-check.sh