This option makes ld use DT_RUNPATH instead of DT_RPATH. DT_RPATH is
generally considered bad because it takes precedence over
LD_LIBRARY_PATH. For example, eog is linked with -rpath /usr/lib/eog,
and with DT_RPATH if an old eog is already installed we are basically
impossible to debug a new eog build w/o overwriting the system
installation first or explicitly using "ld.so --inhibit-rpath" to
invoke it.
This "new" actually means "new in 2000," it's 24 years ago and all other
distros has enabled it. Thus I guess some unexplainable "test suite
uses installed library instead of the just built one" issues in BLFS are
actually caused by this difference: the package author just assumes
everyone is using DT_RUNPATH thus they just set LD_LIBRARY_PATH and
consider it enough to test with the just built libraries, but DT_RPATH
breaks this expectation.
Let's eliminate the difference as it seems not doing anything good and
doing so just takes one switch.
"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.
Disable building nscd in glibc.
Update to iana-etc-20230929.
Update to vim-9.0.1968.
Update to openssl-3.1.3.
Update to meson-1.2.2.
Update to man-db-2.12.0.
Update to linux-6.5.5.
Update to kmod-31.
Update to kbd-2.6.3.
Update to gettext-0.22.2.
Update to bc-6.7.0.
I've not bothered to write an explanation for --disable-crypt because it
will likely be the default of Glibc-2.38, then we may drop it from the
command lines.
Update the rationale for min-kernel in hostreqs. Add a note in
general.ent about the EOL of current min-kernel. Realign the
backslashes in glibc instructions.
"The command below shows an example of nested command substitution
using two methods: backquotes and a $() construct. It could be
rewritten using the same method for both substitutions, but is
shown this way to demonstrate how they can be mixed. Generally
the $() method is preferred."
We need to enable decimal float here or MPFR will be built w/o decimal
float support. Then 2 of 183 tests will be skipped, and this will also
cause an ICA issue.
Q: Why we need decimal float in pass 1?
A: We need pass-1 GCC with decimal float support to build decimal float
routines in pass-2 libgcc.
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.
