The original warning is inaccurate/misleading in many aspects.
The critical thing is GCC version. There's nothing to do with the
OpenSSL version (as nothing in ch5 or 6 ever uses OpenSSL). There's
also nothing to do with the kernel "major" version as the "major"
version is just an arbitary choice to make the minor version not greater
than 19 by Linus. It does not imply any aspect of the ABI, unlike the
"major" version in a SONAME or something. The inablility to build Glibc
with Linux 7.0 API headers is simply a coincidence. If another API
header change happens in Linux 7.6, it may break Glibc build as well.
And I cannot see how the Linux API header version of the host distro can
ever affect LFS. LFS builds ch05 Glibc with its own Linux API header
installed just before Glibc, not the installation from the host distro.
So Glibc should just build fine with the 6.19 API header just installed
into $LFS/usr/include. I know it would fail to build with Linux 7.0 API
headers but why it can ever find one - if it really finds the host
distro's API header instead of the one in $LFS/usr/include we have a
serious bug and it will have to be fixed instead of papered over by
limiting the host distro.
I also know the req test will fail if the host distro has Linux 7.0 but
I've no idea if the test failure is really related to the "massive
breakage of rseq" (I assume it refers to the jemalloc breakage? But
AFAIK nothing in LFS uses jemalloc). And the glibc upstream has just
fixed the test file simply. We always treat test-file-only fixes as
"known failures" instead of "bugs requiring a fix" unless it aborts the
entire test suite too early. Add a note in the glibc page to note there
can be additional failures with Linux >= the version we use for LFS.
And there's also nothing to do with the "rolling release." For example,
you cannot build LFS 12.0 on LFS 12.4 because ch06 bash uses the host
compiler to build some code generators, and those generators are not
compatible with C23 (the default of GCC 15.2 shipped by LFS 12.4). LFS
12.4 is definitely not a rolling release...
A rolling release just catches the breakage earlier and we shouldn't
blame it to do so. IMO we should avoid the unfair accusion on rolling
distros as the same unfair accusion is often towards LFS (notably the
way we develop BLFS is very similar to a rolling release distro).
In the hostreqs page we already states building with a GCC newer than
the version specified for LFS in the book is "not tested and not
recommended." I don't know why people must ignore it (AFAIU "not
recommended" in LFS means "not supported; don't report any bug" already:
for example those "recommended" dependencies in BLFS). Make it more
explicit with assertive language and <warning>.
Twice in the past span of a year, Arch Linux has updates to new versions
of software rather quickly that causes LFS to be impossible without
modifications. The first instance was updating to GCC-15.1, of which
that disaster may be repeated with GCC-16.1. The second, most recent,
instance is that they updated to Linux-7. This changed behavior of
rseq, tables, and the ABI feature from 32 to 33, which messes with
Glibc, meaning users will need to use a host that has Linux <= 6.19.x
for now.
This distructive nature needs to be explained to the users to help to
prevent them from using broken hosts.
So many issues have popped up over on Discord and Reddit, and as an
aside and personal vent, I've been getting pretty tired of it each time
Arch pulls off something like this when it clearly isn't time yet.
The Gentoo GUI LiveCD (and Gentoo itself in general) is a good example
of how to treat the software set, and too not update too early.
Fix the explanation for CSM (here M stands for Module, not Mode).
Keep the terminology "BIOS" soly for "booting via MBR" and use
"firmware" instead for other purposes.
Technically the swap partition does not contain a file system, thus
"formatting" seems puzzling. And the next section is using a better
terminology "initialized" (copied from the man page of mkswap).
This doesn't replace Systemd or SysVinit rendering options.
When going through, I discovered some issues with the main OpenRC branch
which I fixed along the way. There is a UEFI issue I'm embarresed I
didn't notice yet, which was a /boot/efi entry in the /etc/fstab
section. So I will resolve that soon here.
In most cases, there is no need for x32-bit support unless the main
architecture being used is x32-bit support, not 64-bit. Please read the
x32-bit removal announcement for more information if curious.
GCC-15 has bumped the C++ standard to C++14, and the required GCC
version to 5.4 because 5.3 and earlier may generate some wrong code with
C++14 and constexpr (that GCC-15 code base uses).
I know some distros are using a different default and we are having
reports of some mysterious permission issue via lfs-support those I
highly suspect as some umask issue. Let's just explicitly set it (like
setting $LFS) to protect us from such distros without changing every
"mkdir -pv" to "install -vdm755".
Switch to the new kernel config rendering infrastructure. Remove the
"IA32 a.out support" which is already removed and was completely useless
for multilib even before the removal. Mention the new "IA32 emulation
disabled by default" option. Separate mx32 and m32 kernel
configuration. Fix the consequences building a multilib when lacking
the corresponding kernel feature.
