Cross-Chapter 5

This (temporary) page is meant to collect notes, ideas and even issues in regard to the new "Cross-Chapter 5" (CC5). This page might be used in the very early stage of developing the CC5 to avoid mixing issues into the "classic" ticket system which might be seen as kind of pollution. Later on, if CC5 goes live, this page should be deleted and resume normal operation as usual.

Note: This page is not a documentation page. It is a work document everyone (who has write-access) is invited to change things and leave comments!

What is Cross-Chapter5

The modified build uses the cross compiler to cross compile packages that need themselves to be rebuilt, thus insulating them automatically from the host, without the need for a non standard directory layout. Chroot is entered as soon as possible, and the remaining chapter 5 packages are built in chroot.

pros

no /tools symlink, no need to tweak gcc sources, no need to build twice ld in binutils-pass2, no need to readjust the toolchain after chapter 6 glibc, no need to tweak the gcc specs, no need to reinstall kernel headers in chapter 6, no need for symlinks between /usr and /tools in chapter 6.

cons

chroot is entered in the middle of chapter 5 (maybe chapter 5 should be split), the debug sections of several packages reference x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu (but actually, not very serious, since it occurs only for source files that do not generate code, so gdb is usable anyway), binutils-pass2 needs "enable-shared" (this was added for clean ICA, maybe it can be removed).

ToDos

• Topic 1
• Topic 2
• ...

Notes

• Note 1
• Note 2
• ...

Discussion topics

Book layout

We have in the middle of chapter 5 an enter of the chroot environment. Typically, this is seen in the classic mechanism as the start of building the final system, therefore it was organized in a separate chapter, Chapter 6.

In the new mechanism, this is no longer true. Entering the chroot environment the first time does not mean that now the build of the final system is startet. The activities in chroot env at this time are still to prepare the toolchain. So, to make it more clear to the user, there are some options:

1) Introduce a new chapter

• Chap 5: cross toolchain and cross built packages
• Chap 6: temporary toolchain
• Chap 7: final system
• then for following chapters, add 1

2) Keep classic organization

• Chap 5: cross toolchain and cross built packages
• Chap 6: final system
• numbering of (following) chapters untouched

but leaving the chroot env at end of chap5 and enter it again at the beginning of chap6. This seems quite redundant but it provides a logical cut between the two chapters as well as provides an exact entry point where building of the final system starts. That means, between leaving chroot after chapter 5 and reentering it at the beginning of chapter 6, this is the moment where the toolchain can be backed up.

Issues

This is a collection issues which has been seen so far with CC5.

Terminal problem in chroot

Issue

In the first phase of chroot terminal is not quite usable (no backspace key etc).

Solutions

• remove --disable-db-install from the ncurses chap5 configure. This means that tic should be present on the host with a suitably recent version (>= 6.0)
• build tic from the ncurses package with build host tools, and use it to compile the terminfo database when cross-building ncurses
• build with --disable-db-install and copy the /usr/share/terminfo database from the build host to the target lfs host (taints target in some way, who knows what is exactly in that database?).
• build with --disable-db-install, then run the built tic to install the terminfo database (taints cross compile, but the most economical)

Phenomenon on ArchLinux

glibc in ch6 failes with "bison: m4 subprocess failed" (Moody, 04.05.2020)

(BLOCKER: solved/workaround)

While it has been reported (in IRC) that others have build CC5 successfully on Arch, here is what happens when compiling glibc in Chap6 after installing man-pages:

...
make  subdir=intl -C intl ..=../ subdir_lib
make[2]: Entering directory '/sources/glibc-2.31/intl'
.././scripts/mkinstalldirs /sources/glibc-2.31/build/intl
.././scripts/mkinstalldirs /sources/glibc-2.31/build/intl
mkdir -p -- /sources/glibc-2.31/build/intl
.././scripts/mkinstalldirs /sources/glibc-2.31/build/intl
mkdir -p -- /sources/glibc-2.31/build/intl
LC_ALL=C gawk '!/^"POT-Creation-Date: [0-9-]+ [0-9:+-]+\\n"$/' ../po/de.po > /sources/glibc-2.31/build/intl/tst-gettext-de.po
bison --yacc --name-prefix=__gettext --output /sources/glibc-2.31/build/intl/plural.c plural.y
echo '' > /sources/glibc-2.31/build/intl/stamp.oST
plural.y:46.1-7: warning: POSIX Yacc does not support %define [-Wyacc]
   46 | %define api.pure full
      | ^~~~~~~
plural.y:47.1-7: warning: POSIX Yacc does not support %expect [-Wyacc]
   47 | %expect 7
      | ^~~~~~~
mv -f /sources/glibc-2.31/build/intl/stamp.oST /sources/glibc-2.31/build/intl/stamp.oS
bison: m4 subprocess failed: No such file or directory
make[2]: *** [Makefile:46: /sources/glibc-2.31/build/intl/plural.c] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/sources/glibc-2.31/intl'
make[1]: *** [Makefile:470: intl/subdir_lib] Error 2
make[1]: Leaving directory '/sources/glibc-2.31'
make: *** [Makefile:9: all] Error 2

This all does not happen when running the build on a LFS-SVN host.

Discussion

There are only warnings, then the error is about a missing file when running the m4 subprocess. To troubleshoot: type m4 and ldd /usr/bin/m4, also try to run bison with a verbose switch.

It turns out (using strace) the bison expects m4 to be in /bin. Here is at least a workaround:

Exec in Chapter 5a (non-chroot, at m4 or bison)

ln -svf ../usr/bin/m4 $LFS/bin/

or pass M4=/usr/bin/m4 to configure for bison.

works

or move bison (and flex) to chroot.

+ m4 ??

or if [ -L /bin ]; then PATH=$LFS/tools/bin:/usr/bin; else PATH=$LFS/tools/bin:/bin:/usr/bin; fi

Solution

one of the discussed above. Not yet decided

---

tar reports "write error" (Moody, 04.05.2020)

(NORMAL: -/non-critical)

Description

This is caused by using tar in a pipe like

tar -tf tarname.tar.xz | head -n1

in order to retrieve the directory name of the package. The error is not 'nice', but at the end, its harmless.

Discussion

Also, when in chroot, tar reports tar: write error just like this one discussed ten years ago: ​https://www.mail-archive.com/lfs-support@linuxfromscratch.org/msg13073.html
For the tar issue, is it in a pipe? The mailing list thread concluded that it was related to a change in the way the SIGPIPE signal was handled.

A: Yes it is used in a pipe: pkgdir=$(tar -tf ... | head -n1)

Solution

<none>