We only need a one-line change in upstream fix (because we don't use
"make --shuffle"). Add it as a sed for both Chapter 5 and Chapter 8.
Note that the "minimal" sed would be '/MAEKFLAGS :=/s/r/ -r/'. I
included an additional ')' so it won't modify "-r" again to "- -r".
Tested "make" and "make check" on a x86_64 with -j8 and an arm64 with
-j24.
Link: https://sourceware.org/git/?p=glibc.git;a=commit;h=2d7ed98add14
When I changed the sanity check to remove the "dummy.c" file, I
inadvertently used "gcc" instead of "$LFS_TGT-gcc". Which of course
finds the host gcc...
Expand tabs to 8 spaces like everywhere else in the book.
Explain that shared libraries are already covered by ASLR, PIE expands
the ASLR to cover the exetutables.
In 2022, stack smashing attackings are mostly constructing a sequence of
faked returning addresses to exectute a series of function already
existing in the programs or libraries itself (ret2lib). Returning into
the code injected by the attacker is almost impossible because on
i686 (with a PAE/NX enabled kernel) or x86_64, running injected code
needs W/X mappings and those are very rare these days.
Committing only the commands for now, so that others can test the
build. TODO:
- add command explanations
- add changelog
- comment on failing tests in binutils and gcc
It seems glibc creates dummy.c for its own use. This leaves some
dummy.xxx files in the directory, that may lead some users to think that
the directory is not properly cleaned up after the test (I did :)
So use a pipe so that only a.out is created
They are really harmful. In Binutils pass 2, libstdc++.la caused the
building system to use host /usr/lib/libstdc++.so for gprofng. We now
has disabled gprofng for pass 2, but the similar issue also exists in
GCC pass 2. In a normal LFS build, the building system silently uses
/usr/lib/libstdc++.so (I guess it does not blow up simply because some
blind luck); in a real cross build (x86 -> ARM for example) the build
will fail.
Remove the .la files to fix this issue. Instead of only modifying
clfs-ng, it makes more sense to apply the change for trunk: though
the build does not fail, using host library is still a contamination.
This is the issue preventing us from cross-compiling libstdc++ in
Chapter 6. By fixing this issue we can remove a seperate pass 2 for
libstdc++ and simplify the instruction.
The upstream fix will be released in 11.3 and 12.0, so we can remove the
first sed upgrading gcc next time.
A requirement on Glibc is not needed at all. It's enough once
$LFS_TGT-* is runnable. A test on Alpine (using musl as libc) has
practically proved this.
We'd raised binutils and GCC requirements mostly for Glibc. But now
Glibc is cross compiled by our cross toolchain with latest GCC and
binutils release, the host tools really does not matter. In the Glibc
building process only two .c files are build with BUILD_CC (the C
compiler from the host), and they are highly conservative (mostly
unchanged for years).
Binutils does not have too much requirement on host GCC & Binutils:
there is even a Binutils commit in this week fixing a build failure with
GCC-4.2!
So the most strict limitation comes from GCC. GCC requires host GCC to
support ISO C++ 11 so GCC >= 4.8 is needed. And both GCC-4.8 and latest
GCC-11.2 claims a requirement for Binutils-2.12 (for x86_64) or 2.13.1
(for 32-bit x86), so we make minimal Binutils version 2.13.1.
And, host bzip2 is never used now: the only .tar.bz2 files are elfutils
and python docs. They are not decompressed before entering chroot.
"info gccinstall" says:
'--with-glibc-version=MAJOR.MINOR'
Tell GCC that when the GNU C Library (glibc) is used on the target
it will be version MAJOR.MINOR or later. Normally this can be
detected from the C library's header files, but this option may be
needed when bootstrapping a cross toolchain without the header
files available for building the initial bootstrap compiler.
So it can, and should be set to the version of glibc which will be built
for the chroot environment.
On x86_64, currently it does not make any difference with values >=
2.13. But it may make a difference if a new feature is added to glibc,
or on other platforms.
It was moved to chapter 4 during merged-/usr update. However the ln
commands in chapater 4 are "trivial", so move it back to chapter 5 glibc
where we start to use a "different syntactic version" of it.
