When I changed the sanity check to remove the "dummy.c" file, I
inadvertently used "gcc" instead of "$LFS_TGT-gcc". Which of course
finds the host gcc...
Update to Linux-5.19.13
If you are using a laptop with an Intel GPU, it's imperative that you
update immediately if you are running Linux-5.19.12. Failure to upgrade
may result in permanent damage to the LCD display on your laptop.
The root cause of this is improper backporting of bugfixes for the i915
DRM driver in the kernel.
I have:
2 FAIL
5092 PASS
67 UNSUPPORTED
16 XFAIL
4 XPASS
Let's not be too precise (or we'll need to explain the meaning of
"UNSUPPORTED"). IMO "over 5000" is fine (until we get 5500 tests).
Many users will create a user with the same username and UID so the
files will still be owned by his/her. So make it optional by "If you
won't assign the same UID for your user in the LFS system".
If you are using a "modern" distro (with devtmpfs and a modern udev
implementation), a bind mounting is actually not needed because you can
mount devtmpfs anyway. The only reason for bind mounting is to be
compatible with old host distros where /dev is a directory containing
many static device nodes, or is a tmpfs (not same as devtmpfs) popluated
by bootscript or an old udev (modern udev implementations, including
eudev and systemd-udev used by LFS, strictly requires a devtmpfs on
/dev).
So update the explanation to match the status quo.
Chroot command itself does not require kernel VFS mounted. You can mount
/proc, /sys, and /run after entering chroot with
"mount -v -t proc proc /proc" etc. For /dev, if the host kernel
supports devtmpfs, you can also mount /dev in chroot with
"mount -v -t devtmpfs devtmpfs /dev". Even if the host does not support
devtmpfs, it's still possible to mount /proc in chroot, then use
"mount --bind /proc/1/dev /dev".
It's just LFS editors decide to mount them before chroot. So reword
some untrue assertions.
I'm pretty sure "stage 2" libstdc++ (installed in ch6) is already fully
featured. The reason to rebuild the stage 3 libstdc++ (or entire
stage 3 gcc) is same as the reason to rebuild every packages in multiple
chapters: to "settle down" it.
Merge the content of
https://www.linuxfromscratch.org/lfs/faq.html#rebuild-ch8 into the book
as an explanation.
- Don't say "most building system", refine the dicussion for autoconf.
Other building systems may use a variant of triplet, or use a
completely different system designation.
- Explain why a triplet may contain 4 fields in detail. "Histroical
reason" is not really correct because 3-field triplet is still used
today for BSD, Fuchsia, IOS, Mac OS X (darwin), Solaris, etc.
- "machine" triplet to "system" triplet (strictly speaking, only the
first field in the triplet is for the machine).
Why we need to say "vendor can be omitted" explicitly: we mention "gcc
-dumpmachine". On some distros (like Ubuntu) the output has no vendor
field. If you think this is too nasty, please remove both.
Update to iana-etc-20220922.
Update to tzdata-2022d.
Update to readline-8.2.
Update to linux-5.19.11.
Update to libffi-3.4.3.
Update to libcap-2.66.
Update to dbus-1.14.2.
Update to bc-6.0.3.
Update to bash-5.2.
"need to be cross compiled" alone does not make too much sense: we
compile these packages in chapter 8 anyway. The real reason forcing a
cross compilation is circular dependency: if building A needs B but
building B needs A, we'll have to cross compile at least one of A and B
or we won't be able to build either in the chroot.
Many distros have some customized things in gcc -dumpmachine. RHEL uses
x86_64-redhat-linux-gnu, and Ubuntu uses x86_64-linux-gnu ("vendor"
field omitted). So don't use "same" here, and also mention the "vendor"
field is sometimes omitted.
And, don't recommended to "log in as lfs through a DM" anymore: if you
log in through a DM then start a terminal emulator, the first shell in
the emulator is often a non-login shell. It's not something we expect.
"log in" is a specifically defined action on UNIces. When you log in
as a user, an entry will be added into /run/utmp and /var/log/wtmp.
But when you switch to lfs with "su", this won't happen.
"man su" also describes "--login" as:
Provide an environment similar to what the user would expect had
the user logged in directly.
It's "similar to" logged in, not "really" logged in.
So, don't say "log in" or the users may assume they must really log in
as lfs in a VT or DM.
LFS and the host may use different /boot configuration, so do not assume
they'll share a /boot partition (two different /boot partition or only one
with separate /boot are possible).
