As a user of LFS, I appreciate the cleanliness of building the “/tools” directory in Chapter 5, for this simple reason:
I can pause and log out midway through executing chapter 5, and come back - without worrying about re-establishing a “context” like a chroot in chapter 5 would require. If I forget to enter chroot, the mistake can be costly. This is VERY important: if I come back and continue without remembering to restart that chroot (if chroot were used in chapter 5) - I could mess up my current, running Linux system with a build step in chapter 5 that assumes I’m in a chroot environment. Whereas, if I forget the chroot step in Getting back to chapter 6 the next day, rarely does anything bad happen, because the build steps in chapter 6 are mostly such that they are exactly what I’d execute when installing a new version of one of the packages. (Yes, a build of glibc outside of the chroot could cause trouble...) In short, forgetting to enter chroot In chapter 6 has far less possible downside than it would if I forgot in chapter 5. /tools approach in chapter 5 is harder to forget because the use of /tools is part of every build instruction just where it needs to be. There’s fewer assumptions about the current environment. Joel Sent from my iPhone > On May 1, 2020, at 3:58 PM, Ken Moffat via lfs-dev > <lfs-dev@lists.linuxfromscratch.org> wrote: > > On Fri, May 01, 2020 at 03:53:55PM +0200, Pierre Labastie via lfs-dev wrote: >> Hi, >> >> I propose a new way to build LFS, which removes the need for the /tools >> symlink, and decreases the number of tweaks needed when building gcc. >> >> The current build builds a cross-compiler in pass1, and uses it as a >> native compiler in pass2. This needs to use a non standard directory >> (/tools) to host the toolchain and insulate it from the build machine. >> >> 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. >> > > If that happens, entering chroot ought to be after chapter 5. At > the moment, we believe that up to the end of chapter 5 (apart from > when creating the filesystem and setting up the lfs user) you will > not trash the host system. I'm worried about how people will > misinterpret what they should be doing if they come from our present > builds, particularly if they have created their own scripts. > >> This is WIP: the text must be improved at several places, bison and >> flex may be moved to after chroot (to be tested). But the commands seem >> to produce an acceptable system, with almost clean ICA. >> >> You can view it at [1], only for sys V since I have not tested systemd >> yet (I do not expect many changes). >> >> There are pros and cons compared to the current method: >> >> 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. >> >> 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, binutils-pass2 >> needs "enable-shared". >> > > Not keen on that in the debug data, although I almost never use it. > >> Another pro, not tried, is that some simple packages built in chapter 5 >> may be built only once if testing them is not required. >> > > Based on experience from Pure LFS (5.0, where tests were introduced) > I don't regard that as a pro :) > >> Comments and suggestions for improvement (there's a lot of room for >> improvement) welcome. >> >> Regards >> Pierre >> >> >> [1] http://www.linuxfromscratch.org/~pierre/lfs-modified/index.html >> > > My main concern with making a change like this is not that we might > break the reliabilty, or the purity (ICA), but that we now > understand most of the things which can go wrong, and we try to > ameliorate them. > > With a revised process, we might lose most of our past knowledge > about how breakage occurs (in the sense of "I saw this, I recall > that I'd done/omitted ...), and therefore how to fix it. > > ĸen > -- > See You Later, Holy Poppadom! > -- Red Dwarf, The Promised Land > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
