= 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. Solution:: 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/ }}} ---- ==== 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 [[BR]] 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::