Well, the analyzer failures are introduced by literally *my* Glibc
change [1] and I'll sort them out for GCC 14...
And the ASAN failures seem caused by the introduction of
__isoc23_strtol (the libsanitizer does not know to intercept it). I'll
test with LLVM once I reach it in BLFS (LLVM is the upstream of
libsanitizer) and make a bug report.
limits-exprparen.c also fails to me, it needs "ulimit -s 65536" instead
of "ulimit -s 32768" in my build but maybe it's caused by my custom
*FLAGS.
[1]:https://sourceware.org/git/?p=glibc.git;a=commit;h=71d9e0fe766a
Well, I forgot to create the man pages tarball as root, so if we don't
use --no-same-owner the man pages will be owned by UID 1000 :(.
Instead of regenerating the tarball again let's just fix this in the
book.
Update udev-lfs tarball to remove obsolete
cdrom rules and references to ISDN devices.
Update to wheel-0.41.0 (Python Module).
Update to tar-1.35.
Update to systemd-254.
Update to meson-1.2.0.
Update to linux-6.4.7.
Update to gcc-13.2.0.
Update to file-5.45.
This partially reverts commit 1053282e5f.
There is actually only one test suite in LFS build even with -k, but on
my complete system there are many test failures with "-k". I guess some
tests depend on non-LFS packages.
The text change is reverted, but the command change is preserved as
generally we should use -k for any make check command known to fail.
I've not bothered to write an explanation for --disable-crypt because it
will likely be the default of Glibc-2.38, then we may drop it from the
command lines.
Update the rationale for min-kernel in hostreqs. Add a note in
general.ent about the EOL of current min-kernel. Realign the
backslashes in glibc instructions.
Use "library name" (instead of "library version") for SONAME (for now).
And "conflicting locations" may not be a problem if the symbol is at two
locations but they are exactly same (or ABI compatible).
For the details see lfs-dev discussion.
The current word is still not perfect (we've not defined "the name of a
shared library" at all), so I guess we'll need to make a major revision
for the entire "upgrading issue with shared libraries" thing in the
future.
remap="configure" means it is for configuring the build before
running make (or ninja), not for configuring the system
after the package is installed. We don't have a special attribute
for that.
TODO: HWAsan needs Linux 6.4 (not released yet) and a recent Intel CPU.
So it the kernel and hardware support is available, we may see more
test failures. I'll try it out on my new system...
