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 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.
It does no good: normally we have -v for chown so once it no longer has
an effect we can know, but in this case these chown commands will never
have no effect. And a huge amount of output with -v wastes the server
storage and bandwidth (for both the server and the people reading the
build logs).
libcpp is the preprocessor library, but it's a static library which is
only used by GCC itself and not installed.
libcc1 is actually a library for GDB to "compile" expressions, so we can
use fancy expressions in commands, like "print sin(x + 2.0)": the
expression sin(x + 2.0) needs to be "compiled" for evaluation.
Update to xz-5.4.4.
Update to less-643.
Update to meson-1.2.1.
Update to linux-6.4.10.
Update to iana-etc-20230810.
Update to pkgconf-2.0.1.
All build times and sizes were also checked and updated as needed.
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
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.
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...
names of packages. Clarified verbiage in re PIE & ASLR. Improved the
description of SSP, and tightened it up. Clarified the instructions
for running tests concurrently. Modified descriptions of tests that
fail. Patched up punctuation. Spelled "set up" correctly: "setup" is
a noun. The phrasal verb used here is spelled as two words. Use the
word "directives" to describe "#include" and similar preprocessor
instructions. Add periods to some otherwise complete sentences.
