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.
The effect will not change, but with symlinks ld can save some time
invoking open(), read(), etc. syscalls and parsing the linker scripts.
Note that I've also removed "libcursesw" symlink because this library
has never existed. Instead libcurses.so is created as a symlink
direct to libncursesw.so.
instead of the 8-bit ncurses.
We don't provide the 8-bit ncurses library and we are "faking" it using
ncursesw. Thus innocent package may be compiled with the 8-bit ABI
(because it does not know what we are doing and so it does not use
the "expected" preprocessor definitions to enable the wide ABI) but
linked against ncursesw, causing a potential ABI mismatch.
Well, I was blaming libtool too much. If the entire Binutils tree uses
libtool this won't happen. The problem is Binutils building system is
using libtool-style idiom on non-libtool components.
And this issue is not related to cross compiling, at all. A native
build can exploit the issue as well (see the updated comment).
Maybe I'll submit a patch to GCC (yes, not a typo, GCC is the upstream
of Binutils building system) to fix the issue when I have the mood...
