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.
Update to bash-5.2.32.
Update to iana-etc-20240801.
Update to vim-9.1.0660.
Update to binutils-2.43.
Update to linux-6.10.3.
Update to readline-8.2.13.
Update to wheel-0.44.0.
Update to iana-etc-20240723.
Update to glibc-2.40.
Update to iproute2-6.10.0.
Update to linux-6.10.2.
Update to lz4-1.10.0.
Update to meson-1.5.1.
Update to setuptools-71.1.0.
Update to sysklogd-2.6.1.
Update to systemd-256.4.
Update to sysvinit-3.10.
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.
Update to iana-etc-20240612.
Update to bc-6.7.6.
Update to man-pages-6.9.1.
Update to linux-6.9.7.
Update to sysklogd-2.5.2.
Update to shadow-4.16.0.
Update to systemd-256.1.
Update to setuptools-70.1.1.
Also change the formatting of options '-Dsomething' to '-D something'.
Update to vim-9.1.0478.
Update to iana-etc-20240607.
Update to systemd-256.
Update to python3-3.12.4.
Update to perl-5.40.0.
Update to openssl-3.3.1 (Security fix).
Update to linux-6.9.4.
Update to findutils-4.10.0.
Update to meson-1.4.1.
Update to xz-5.6.2.
Add linux-6.9.x compatibility instructions to systemd and udev.
Update to setuptools-70.0.0 (python module).
Update to ninja-1.12.1.
Update to man-pages-6.8.
Update to linux-6.9.3.
Update to libcap-2.70.
Update to iproute2-6.9.0.
Update to e2fsprogs-1.47.1.
Add security fix to glibc.
Update to linux-6.8.8.
Update to ncurses-6.5.
(cherry picked from commit d0ca5ead46)
Reapply this change which is mistakenly reverted in
340e17adc6.
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.
Update to setuptools-69.5.1.
Update to python3-3.12.3.
Update to openssl-3.3.0.
Update to ninja-1.12.0.
Update to man-db-2.12.1.
Update to linux-6.8.6.
Update to iana-etc-20240412.
Update to vim-9.1.0330.
The test hang issue is not related to partial environment. It's just a
known issue (for eg https://github.com/python/cpython/issues/91155) and
happens when we are unlucky.
So just run the test suite with a timeout. 1 SBU should be enough: it's
approximately 4 times of the time used by the slowest test case, on both
an old Athlon 64 3000+ and a Core i5-11300H.
I've not seen any test failure on a complete system (the expat-related
failure seems fixed by expat-2.6.2 or 2.6.1). TODO: really test this
with LFS chroot and document failures if any.
Update to iana-etc-20240318.
Update to zstd-1.5.6.
Update to util-linux-2.40.
Update to shadow-4.15.1.
Update to pkgconf-2.2.0.
Update to linux-6.8.2.
Update to coreutils-9.5.
Update to wheel-0.43.0.
Update to setuptools-69.2.0 (Python module).
Update to meson-1.4.0.
Update to expat-2.6.2 (Security fix).
Update to iana-etc-20240305.
Update to vim-9.1.0161.
Update to xz-5.6.1.
Update to shadow-4.15.0.
Update to psmisc-23.7.
Update to kmod-32.
Update to elfutils-0.191.
Update to iana-etc-20240222.
Update to vim-9.1.0145.
Update to xz-5.6.0.
Update to tcl-8.6.14.
Update to shadow-4.14.6.
Update to setuptools-69.1.1.
Update to linux-6.7.7.
Update to libffi-3.4.6.
Update to gettext-0.22.5.
Update to expat-2.6.1.
So if a test times out, it will be noted in jhalfs log.
Also remove "-l" so the output will be something like
./nptl/tst-thread-affinity-pthread: Timed out ...
instead of just a puzzling "./nptl/tst-thread-affinity-pthread".
As we've already concluded, overwriting a shared object can crash
running processes using code or data from this shared object. For
example if gdm is crashed, we may leave the system unusable :(.
I spent some time investigating the difference of vim test results from
different editors. It turns out the value of TERM can affect the test
results in a deterministic way: when TERM=xterm-256color all tests pass,
when TERM=linux one test fails, and when TERM=vt100 20+ tests fail.
As we are redirecting the output to a file, the actual type of the
terminal does not matter and we can just specify a value known to work.
Glibc tests occansionally fail due to a timeout because:
1. The hardware is slower than the developers expected.
2. Some tests use multiple or even all CPU cores internally, for e.g.
with 8 active CPU cores we may end up running 8 tests (due to -j8)
each of them uses 8 cores in the worst case, resulting a severe
congestion.
I'm almost sure nptl/tst-thread-affinity* are cases of 2.
Let's document how to rule out the timed out tests instead of making the
list of known failures longer and longer.
