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.
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).
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.
Use <quote> instead of '"' if possible. Use <literal>,
<computeroutput>, etc. instead of <quote> if possible. Replace
<quote>alpha</quote> with a UTF-8 Greek alpha character.
BTW decorate ".link" with <filename class='extension'>.
We'll use nproc for setting MAKEFLAGS and TESTSUITEFLAGS. And if nproc
is not available, we'll end up with "MAKEFLAGS=-j" which is very
dangerous because it allows make to spawn infinite number of jobs.
Check it early.
The nproc program is added in Coreutils 8.1 so we need to bump the
minimal version.
Update the rationale for min-kernel in hostreqs. Add a note in
general.ent about the EOL of current min-kernel. Realign the
backslashes in glibc instructions.
1. Declare UNIX98 PTY requirement in host system requirements and check
it in the script. All desktop or server distros should have it now,
but let's stop anyone from building on a embedded distro w/o UNIX98
PTY early...
2. Use Expect test suite as a guard against mishandled $LFS/dev/pts.
3. No need to test the basic function of Expect in Binutils anymore
because if ($LFS)/dev/pts is not good, the Expect test suite would
have failed.
- Remove an extra whitespace breaking shebang (though our instruction
does not use the shebang).
- Adjust the regex to allow several letters after the version number,
and match grep version to the text.
- Raise Coreutils to 7.0 (for the host requirement script itself). It
was released in 2008 so I don't think it's a problem.
- Add a colon after the text "Compiler check" to match "Aliases:".
- Use grep -o instead of sed to make kernel version check simpler.
