"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).
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 jinja2-3.1.3 (#5411)
- Update to bc-6.7.5 (#5408)
- Update to attr-2.5.2 (#5412)
- Update to ncurses-6.4-20230520 (#5416)
- Update to markupsafe-2.1.4 (#5418)
- Update to linux-6.7.1 (#5406)
- Update to iproute2-6.7.0 (#5410)
- Update to vim-9.1.0041 (#4500)
- Update to iana-etc-20240117 (#5006)
- Update to shadow-4.14.3 (#5413)
The effect will not change, but with symlinks ld can save some time
invoking open(), read(), etc. syscalls and parsing the linker scripts.
Note that I've also removed "libcursesw" symlink because this library
has never existed. Instead libcurses.so is created as a symlink
direct to libncursesw.so.
instead of the 8-bit ncurses.
We don't provide the 8-bit ncurses library and we are "faking" it using
ncursesw. Thus innocent package may be compiled with the 8-bit ABI
(because it does not know what we are doing and so it does not use
the "expected" preprocessor definitions to enable the wide ABI) but
linked against ncursesw, causing a potential ABI mismatch.
- replace some characters by their utf-8 encoded equivalent (and change
encoding in the <?xml?> line
- replace 
 with a true newline char. This is somewhat more readable
anyway.
We don't use it and it uses ( for opening parenthesis.
I am not sure whether this has some reason or not, but
we want to get reed of &#xx; chars in our change to utf-8,
so easier to remove than to find out why...
In chapter 6, patch configure outputs:
libattr development library was not found or not usable.
GNU patch will be built without xattr support.
While this is normal in chapter 6 (building a temporary patch), we
should mention this dependency in the dependencies page.
The template named generate-basic-index in
{docbook-xsl}/xhtml/autoidx.xsl has a bug that generates a div element
with a wrong xmlns:xlink attribute. See
https://github.com/docbook/xslt10-stylesheets/issues/239.
Rather than fixing docbook-xsl, which would work only in LFS (but we
want to be able to render on other distros), copy the faulty template
to our customization files (lfs-index.xsl), so that this one is used.
We can also simplify it a lot since we don't need all the cases
covered in general docbook-xsl.
For some reason, the stylesheets generate a
<div xmlns:xlink="http://www.w3.org/1999/xlink" ...> element in
longindex.html, but this is not valid in xhtml (the attribute
xmlns=xlink is not defined in the DTD). The problem is that tidy then
thinks it is not a true xhtml and removes the doctype declaration.
But when a browser receives a file without doctype declaration, it
thinks it uses an old standard, and switches to "quirks mode"
(for firefox, this can be seen by typing ctrl-I on the page).
