Some user using a slow system complained (off-list) to me that the long
no-output period seemed like a hang (esp. combined with the warning
about missing re2c).
Also explain the "basic functionality test" is already done, so no need
to run "./ninja" again for testing.
This reverts commit dc8572f241.
The permission issue seems fixed upstream: after I untar the tarball
with --no-same-owner --no-same-permissions as root, all files are 644
and all directories are 755 (proven via find -type f -not -perm 644 and
find -type d -not -perm 755).
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.
Update to vim-9.1.1016.
Update to iana-etc-20250108.
Update to util-linux-2.40.4.
Update to sysvinit-3.13.
Update to sysklogd-2.7.0.
Update to shadow-4.17.2.
Update to setuptools-75.8.0.
Update to linux-6.12.9.
Update to gettext-0.23.1.
This reverts commit 8f493a6377.
When I was building LFS, I somehow forgot to mount /dev/sdb7 to
/mnt/lfs on my system. I ended up chrooting into /mnt/lfs, and it was a
directory, not a filesystem.
This happens from time to time, not sure why I did it this time!
The tests that I had marked as failed no longer fail, but at the same
time, now test-namespace does. Let's undo this commit...
The upstream fix is explicitly checking libxml2 version so it's not
practical to be turned into a sed. But I don't want to upload another
patch just for such a "temporary" issue (as it'll be fixed for 0.23.1
anyway). This alternative fix relies on:
1. The fact that the return type of xmlCtxtGetLastError and the arg type
of xmlStructuredErrorFunc are changed in the same commit
61034116d0a3 ("error: Make more xmlError structs constant").
2. GCC supports typeof(expr) to get the type of expr w/o really
evaluating it.
So it should have the same effect as the upstream fix.
Tested with both --with-included-libxml2 and --without-included-libxml2
on BLFS.
The second expression
's/xmlError *err/const &/'
does nothing, because " *" actually matches zero, one, or several white
spaces, not a white space and an asterisk.
And the first expression
'/libxml\/xmlerror.h/i #include <libxml/xmlversion.h>'
includes a header, but we are not using anything in the header.
The intention of the sed command is fix a compatibility issue with
system libxml, but LFS does not have a system libxml so the fix is not
needed for LFS. And, if we just fix up the second expression to
's/xmlError \*err/const &/'
making it actually work, it'll cause a FTBFS with shipped libxml (used
in LFS because system does not have libxml), so we cannot easily fix it
either.
For now just remove the sed. If gettext-0.23.1 isn't released before
LFS 12.3 freeze, we can either apply the upstream patch to make it work
for both shipped libxml and system libxml, or add the corrected sed with
"nodump" and some alarming texts.
Update to vim-9.1.0927.
Update to iana-etc-20241206.
Update to systemd-257.
Update to Python-3.13.1.
Update to libcap-2.73.
Update to linux-6.12.5.
Update to kbd-2.7.
Update to gettext-0.23.
Update to file-5.46.
Update to iproute2-6.12.0.
Update to libtool-2.5.4.
Update to linux-6.12.1.
Update to setuptools-75.6.0 (Python Module).
Update to wheel-0.45.1 (Python Module).
It's not needed now and I don't know why it was added in the first place
(at r10573-g2e8cbe04cdac). I'd say it likely just covered up some user
error (for e.g. simply forgetting "make" before "make install").
Removing it anyway and if it turns out something bad is happening we can
always revert.
Update to vim-9.1.0866.
Update to iana-etc-20241024.
Update to wheel-0.45.0 (Python Module).
Update to setuptools-75.5.0 (Python Module).
Update to linux-6.11.8.
Update to libcap-2.72.
Update to iana-etc-20241015.
Update to vim-9.1.0813.
Update to xz-5.6.3.
Update to sysvinit-3.11.
Update to setuptools-75.2.0.
Update to Python3-3.13.0.
Update to openssl-3.4.0.
Update to meson-1.6.0.
Update to markupsafe-3.0.2.
Update to linux-6.11.5.
Update to less-668.
Update to elfutils-0.192.
Update to Python3-3.12.7.
Update to tcl9.0.0.
Update to linux-6.11.1.
Update to libtool-2.5.3.
Update to iproute2-6.11.0.
Update to bash-5.2.37.
Update to bc-7.0.3.
Update to vim-9.1.0738.
Update to texinfo-7,1,1.
Update to tcl8.6.15.
Update to sysklogd-2.6.2.
Update to setuptools-75.1.0.
Update to meson-1.5.2.
Update to iana-etc-20240912.
Update to gawk-5.3.1.
Update to bc-7.0.2.
I've had doubts on this "ulimit -s 32768" command for years. After
reading GCC code (libiberty/stack-limit.c) I'm pretty sure this command
is not doing what we expected.
In a typical Linux distro, the default "soft" stack limit is 8 MiB and
the default "hard" stack limit is infinite. And GCC will automatically
increase the soft limit to 64 MiB if the original soft limit is smaller
than 64 MiB, and the hard limit is at least 64 MiB. So with a typical
default configuration, the real stack limit of GCC is 64 MiB.
But our "ulimit -s 32768" command sets both the soft limit and the hard
limit to 32 MiB. Thus we are actually *decreasing* the real stack
limit. Fortunately this has not caused any test failures, but it's just
wrong (contradicting with the explanation of the command).
Thus just raise the hard limit to infinite in case the host distro uses
a not so typical configuration where the hard limit is tight, and let
GCC to set up the soft limit to the expected value on its own. It's
more future-proof than "ulimit -s 65536" in case GCC changes the
expected stack limit in the future.
It should be safe to make the change in freeze because in jhalfs it only
affects the test suite, and even in a manual build the user can skip
this command if not running the GCC test suite.
