on the systems without non-loopback IP address
We'd observed this long ago with "unknown reason". I just saw it again
and did some investigation, found it depends on getaddrinfo() with
AI_ADDRCONFIG, which requires a non-loopback address.
A requirement on Glibc is not needed at all. It's enough once
$LFS_TGT-* is runnable. A test on Alpine (using musl as libc) has
practically proved this.
We'd raised binutils and GCC requirements mostly for Glibc. But now
Glibc is cross compiled by our cross toolchain with latest GCC and
binutils release, the host tools really does not matter. In the Glibc
building process only two .c files are build with BUILD_CC (the C
compiler from the host), and they are highly conservative (mostly
unchanged for years).
Binutils does not have too much requirement on host GCC & Binutils:
there is even a Binutils commit in this week fixing a build failure with
GCC-4.2!
So the most strict limitation comes from GCC. GCC requires host GCC to
support ISO C++ 11 so GCC >= 4.8 is needed. And both GCC-4.8 and latest
GCC-11.2 claims a requirement for Binutils-2.12 (for x86_64) or 2.13.1
(for 32-bit x86), so we make minimal Binutils version 2.13.1.
And, host bzip2 is never used now: the only .tar.bz2 files are elfutils
and python docs. They are not decompressed before entering chroot.
Approved by bdubbs for 11.1.
To editors: no need to rebuild system and re-tag anything, AFAIK nothing
in BLFS uses libsubid now. You may delete /usr/lib/libsubid.a on your
system manually.
Add libc_malloc_check.so (it's like libmcheck.a, but should be used with
LD_PRELOAD).
Add description for libmvec.
"libnss" -> "libnss_*", and reword the description.
Add binutils-2.38 LTO patch.
Update to util-linux-2.37.4.
Update to man-db-2.10.1.
Update to linux-5.16.9.
Update to vim-8.2.4383.
Update to iana-etc-20220207.
A very old libtool copy (2009-11-29) is shipped in binutils tarball. It
does not support sysroot, so the cross-built binutils binaries may link
to libraries from the host distro, if certain libraries are available.
The ideal solution should be updating libtool, as libtool-2.4.6 (in LFS)
has sysroot support. However, updating libtool for binutils is not
trivial: it would require to rerun autoconf and binutils building system
sticks to autoconf-2.69. Another issue is the sysroot support for
libtool has introduced a configure option "--with-sysroot", which
conflicts with an already existing option with the same name in
GCC and binutils building system (we are using the GCC/binutils version
of --with-sysroot in chapter 5).
GCC building system has --with-build-sysroot (we are using this for GCC
pass 2) for this issue. Binutils copied GCC building system, but it
does not respect --with-build-sysroot.
So for now we just edit libtool code to prevent "-L/usr/lib" in
$LFS_TGT_gcc command line. It should fix the issue about host libiberty
(reported in #lfs-support) as well, but it still need to be confirmed by
someone having such a host.
Tested with a jhalfs run on LFS.
In the new cross-compilation approach, the $PATH in chroot does not
contain '/tools/bin'. So "+h" is useless in chroot as the newly
installed tools always replace the temporary counterpart at the same
location.
"+h" in chapter4/settingenviron.xml is kept deliberately. Currently
$LFS/tools/bin only contains programs prefixed with
"x86_64-lfs-linux-gnu-", and it's highly unlikely that any distro will
ever ship a program named with such prefix. So it may seems that we can
remove this "+h" as well. However, the situation may change in future
and we can take this oppertunity to teach the advantage and disvantage
of bash hash feature.
* tailf is removed completely
* fdformat is disabled by default, and we don't really have any reason
to enable it (and we'll need to workaround the missing man page issue
if we want to enable it)
* irqtop, lsirq, scriptreplay, and uclampset added
