The standard page wasn't adapted for LoongArch since day one. Remove
the references to IA32 and AMD64, and state there's no LoongArch
specific part of LSB. Also we cannot satisify some (really
unreasonable) requirements on symbol versions with Glibc on LoongArch.
By the way drop libutil.so.1 from Glibc contents as it does not exist on
LoongArch.
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=31136#c11
The info has been severly outdated. And some info is even incorrect
from day one, for example even Glibc and GCC are not listed for LSB core
(they provide libc.so.6, libstdc++.so.6, etc.).
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.
Update to tzdata-2024b. Fixes
Update to systemd-256.5. Fixes
Update to setuptools-74.1.2. Fixes
Update to python3-3.12.6. Fixes
Update to openssl-3.3.2. Fixes
Update to man-db-2.13.0. Fixes
Update to linux-6.10.8. Fixes
Update to libpipeline-1.5.8. Fixes
Update to expat-2.6.3. Fixes
Update to bc-7.0.1. Fixes
+
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.
If CONFIG_FB is not set but CONFIG_DRM_FBDEV_EMULATION is set to y, on a
DRM-drived graphic card (anything from AMD/ATI, Intel, or NVIDIA in
recent 20 years) we'd be using a fb console but without
/sys/class/graphics/fb0. Then the script won't run setfont for VT 2-6.
Check /sys/class/graphics/fbcon instead of /sys/class/graphics/fb0 to
fix the issue.
Closes: https://lists.linuxfromscratch.org/sympa/arc/lfs-support/2024-08/msg00001.html
Reported-by: Alan Ianson <agianson@gmail.com>
It's added after 12.1 release and removed before 12.2 release, so when
we compare 12.1 and 12.2 it's neither added nor removed and it just
seems never existed.
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).
