Fix make-4.4 bug.
Update to wheel-0.38.4 (Python Module).
Update to texinfo-7.0.
Update to sysvinit-3.05.
Update to shadow-4.13.
Update to sed-4.9.
Update to meson-0.64.0.
Update to linux-6.0.7.
Update to elfutils-0.188.
Update to bc-6.1.1.
We only need a one-line change in upstream fix (because we don't use
"make --shuffle"). Add it as a sed for both Chapter 5 and Chapter 8.
Note that the "minimal" sed would be '/MAEKFLAGS :=/s/r/ -r/'. I
included an additional ')' so it won't modify "-r" again to "- -r".
Tested "make" and "make check" on a x86_64 with -j8 and an arm64 with
-j24.
Link: https://sourceware.org/git/?p=glibc.git;a=commit;h=2d7ed98add14
Update to iana-etc-20221025.
Update to tzdata-2022f.
Update to Python3-3.11.0.
Update to procps-ng-4.0.1.
Update to man-pages-6.01.
Update to man-db-2.11.0.
Update to make-4.4.
Update to linux-6.0.6.
Update to libffi-3.4.4.
Update to inetutils-2.4.
Update to expat-2.5.0.
Note: I had to run glibc in Chapter 8 at -j1 to avoid an apparant race
condition. With a little more investigation I may be able to find a
better solution.
The problem is not "gcc building system doesn't know cc-lfs can run on
pc", but "cc-lfs really cannot run on pc".
Let's stop anyone from thinking about "why not just tell the gcc
building system the fact".
Do not use "whether there are any known security vulnerabilities"
because it's highly unlikely there was none.
Many people just build LFS for an experiment, then they don't need to
maintain their system. The maintaining is only necessary for a real
desktop or server system.
RFC 3986:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
So "linuxfromscratch.org" is not a URI, nor "irc.libera.chat".
Well, somehow this paragraph has become too imprecise.
1. We don't support IA64. Both Intel and AMD uses x86_64 now, which is
referred as "AMD64" because it's first proposed by AMD. Intel
attempted to use IA64 (which is a VLIW architecture completely
different with x86_64) to compete with AMD64, but failed. Then Intel
adapted x86_64.
2. The architecture specific part belongs to Core and Desktop.
3. LFS cannot conform to both AMD64 and IA32 because we don't support
multilib. It's "or", not "and".
