The problem is that TIC_PATH is nor honored anymore in chapter
6, so that tic from the host is used to create the terminfo
database in chapter 6. The problem is that old versions of
tic create symlinks in the database, while newer versions
create hardlinks. Since we use a DESTDIR install in chapter 8
(with a recent version of ncurses, so with hardlinks), and copy
it in place with cp -a, then it seems that copying hardlinks to
symlinks. If an old version of tic has been used in chapter 6,
this copies hardlinks to symlinks, which creates symlinks
pointing to themselves (cp bug?).
Anyway, the solution is to copy the auxilliary tic built
in chapter 6 to $LFS/tools/bin (suggestion by Xi Ruoyao).
Now, there is no need to set TIC_PATH or whatever because this
tic is in the PATH.
Bug first reported by Marcin Dulak. Analysis with the help of
Bruce Dubbs and Thomas Trepl.
Fixes https://wiki.linuxfromscratch.org/lfs/ticket/5744
Update to libcap-2.76.
Update to perl-5.40.2 (Security update).
Add packaging-24.2 (Python module). Needed for wheel.
Update to xz-5.8.1.
Update to wheel-0.46.1 (Python Module).
Update to sysklogd-2.7.2.
Update to Python3-3.13.3.
Update to openssl-3.5.0.
Update to meson-1.7.2.
Update to linux-6.14.2.
Update to libffi-3.4.8.
Update to iproute2-6.14.0.
Update to gzip-1.14.
Update to grep-3.12.
Update to gperf-3.2.1.
Update to gawk-5.3.2.
Update to diffutils-3.12.
Update to coreutils-9.7.
This seems just a remnant from the pre-cross-chap5 era. Now with the cross-
toolchain the build system cannot find guile headers and libraries, thus
guile should be disabled by default.
I've also tried this on a host distro with guile installed.
Update to vim-9.1.1071.
Update to iana-etc-20250123.
Update to binutils-2.44.0.
Update to coreutils-9.6.
Update to e2fsprogs-1.47.2.
Update to glibc-2.41.
Update to iproute2-6.13.0.
Update to libxcrypt-4.4.38.
Update to linux-6.13.1.
Update to man-pages-6.10.
Update to meson-1.7.0.
Update to perl-5.40.1.
Update to tcl8.6.16.
Update to tzdata2025a.
Update to xz-5.6.4.
Pass 2 libstdc++ still links to libgcc.a even with LDFLAGS_FOR_TARGET=,
despite this libgcc.a is from pass 2 instead of pass 1.
The difference between pass 2 libgcc and pass 1 libgcc is Glibc wasn't
installed when the pass 1 libgcc was built. This difference causes both
consequences (1) pass 1 libgcc lacks shared library and (2) pass 1
libgcc cannot support C++ EH, but it's not (1) causing (2).
This option makes ld use DT_RUNPATH instead of DT_RPATH. DT_RPATH is
generally considered bad because it takes precedence over
LD_LIBRARY_PATH. For example, eog is linked with -rpath /usr/lib/eog,
and with DT_RPATH if an old eog is already installed we are basically
impossible to debug a new eog build w/o overwriting the system
installation first or explicitly using "ld.so --inhibit-rpath" to
invoke it.
This "new" actually means "new in 2000," it's 24 years ago and all other
distros has enabled it. Thus I guess some unexplainable "test suite
uses installed library instead of the just built one" issues in BLFS are
actually caused by this difference: the package author just assumes
everyone is using DT_RUNPATH thus they just set LD_LIBRARY_PATH and
consider it enough to test with the just built libraries, but DT_RPATH
breaks this expectation.
Let's eliminate the difference as it seems not doing anything good and
doing so just takes one switch.
GCC 14 libsanitizer no longer depends on crypt.h. But let's keep this
option for reducing build time, just update the explanation.
Also remove libxcrypt from GCC depedency list.
Update to vim-9.1.0405.
Update to util-linux-2.40.1.
Update to linux-6.8.9.
Update to jinja2-3.1.4 (Python mpdule).
Update to iana-etc-20240502.
Update to gcc-14.1.0.
