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
