I've proposed a backport of the change to GCC 13.3 but no response yet.
But even if the proposal is rejected I'd still have no choice but
backporting downstream. So just do it.
Though the commit message mentions "recent Binutils and GCC trunk", I'm
99.99% sure this is only related to Binutils since the troubling
R_LARCH_RELAX/R_LARCH_ALIGN is appearing in some object files assembled
from .S files.
IMO this commit should be backported to even 6.1, but Huacai always
believe people using the latest Binutils should use the latest kernel.
And it seems Linux 6.8 won't catch LFS 12.1 package freeze, leaving me
no choice but backporting this downstream.
We want expect to return the return code of "make test" (stored in
$value), but $value is expanded too early to nothing by Bash. Quote EOF
so Bash won't expand $xxx.
We used to run "expect -c 'spawn ls'" for this in Binutils, but then we
thought expect test suite was enough as such a simple PTY test. However
expect test can fail due to some different reason, so add back a simple
test using Python pty module before building expect. Now we no longer
need to consider expect test critical (IIRC there was a report saying
one expect test failed for unknown reason but all other things OK).
IIRC we switched from separate devpts to bind mount, and matched the UID
of tester with the host UID owning the TTY, to satisify the Bash test
suite. But now we are always using UID 101 for tester and expect to
spawn a PTY for Bash test suite (so when building LFS in a TTY owned by
the root user of the host tester won't be UID 0). Thus we can switch
back to a separate devpts mount which is cleaner and safer.
And we are already using a separate devpts mount in Chapter 11.
$(realpath /dev/shm) will return the absolute path of the target of
/dev/shm, thus the command will work for both absolute symlink and
relative symlink.
A Glibc update may contain locale updates, so keep
/usr/lib/locale/locale-archive synced.
Other distros are also doing this when Glibc is updated with the package
manager.
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).
Let's change our policy to match other "rolling release" distros and
ease the procedure to fix Glibc security vulnerabilities.
Squashed the commits in xry111/update-glibc branch to keep the history
clean.
Co-Authored-By: Pierre Labastie <pierre.labastie@neuf.fr>
Co-Authored-By: Douglas R. Reno <renodr@linuxfromscratch.org>
Per a discussion in the team, we only consider an upgradation dangerous
if it may render the system unusable. "Causing something not able to
build" is never considered dangerous. Thus upgrading some headers
cannot be dangerous.
The Glibc portion will need an update too (it can be upgraded safely
with some caution) to ease security updates. But let's do the easy
change first...
Update to openssl-3.2.1.
Update to zlib-1.3.1.
Update to xz-5.4.6.
Update to linux-6.7.2.
Update to iana-etc-20240125.
Update to binutils-2.42.
Update to acl-2.3.2.
Update upstream fixes for readline-8.2.
Apply upstream fix for bash-5.2.21.
The Glibc INSTALL file says:
‘--with-headers=DIRECTORY’
Look for kernel header files in DIRECTORY, not ‘/usr/include’. ...
So --with-headers=/usr/include seems just doing nothing.
Use <quote> instead of '"' if possible. Use <literal>,
<computeroutput>, etc. instead of <quote> if possible. Replace
<quote>alpha</quote> with a UTF-8 Greek alpha character.
BTW decorate ".link" with <filename class='extension'>.
Do not duplicate large paragraphs of texts.
Always use C locale if running in a Linux console. Create /etc/profile
for systemd too, but reading the locale setting from /etc/locale.conf.
- remove some useless --xinclude
- write only one option per line
- use --encode UTF-8 instead of --noent (which is useless after
profiling anyway
- try to be consistent in option order
- use --output instead of -o
If in a series of commands, and not the last, true has no effect
If in the last command, it is better to exit if there is a real
error in tidy, so use "|| test $$? -le 1", but only when tidy is
the last in a series of commands
Part of a patch by Boian Berberov
"gcc(1)" is really not a file name.
Use <ulink> and link to the online man page on
https://man.archlinux.org/ so the user can refer to the man pages more
easily.
The change is done via a sed command and long lines are wrapped
manually.
"Fatal error" is no longer outputted, but "Python requires OpenSSL
1.1.1 or newer" is bad as well because it's not really "required" (at
least in BLFS definition).
