On Fri, 01 May 2020 15:53:55 +0200 Pierre Labastie via lfs-dev <lfs-dev@lists.linuxfromscratch.org> 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. This is very interesting! > > 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. I have always wondered why it was not done like this. Cross-LFS - which originally came from LFS - add another layer on top of this; so in the end gcc was built thrice (cross-compiler, the "/tools" compiler, and then the final native compiler). With your method, cross-lfs could have done it in two-pass - exactly as the same as LFS. > > 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. > Sorry, I'm not familiar with the term. What does "ICA" stands for? > You can view it at [1], only for sys V since I have not tested systemd > yet (I do not expect many changes). I use SysV so this is good enough for me. Not familiar enough with systemd to give any intelligent comment whether more extensive tweaks are needed (especially when tests are involved). > > 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. In my view this is a big pro, especially the "no tweak" part, since it means less breakage when upstream updates gcc. The reduction of the builds is also welcome, though. > > cons: chroot is entered in the middle of chapter 5 (maybe chapter 5 > should be split), Either it it split (Chapter 5A and 5B), or move those sections _after_ the chroot to Chapter 6. Alternatively split and renumber (5A stays as 5, 5B becomes 6, 6 becomes 7) but that's probably an unacceptably big change. > the debug sections of several packages reference > x86_64-lfs-linux-gnu instead of x86_64-pc-linux-gnu, binutils-pass2 > needs "enable-shared". The debug stuff is a let-down - though like Ken, I seldom use it; however it is very handy for the time when I _really_ need to it (and that has happened a couple of times). Which packages are you talking about? Hopefully not glibc/libgcc/libstdc++? > > Another pro, not tried, is that some simple packages built in chapter 5 > may be built only once if testing them is not required. It's nice to have them tested during development builds (=when the book is being updated). But it's also nice to have options to skip these for the "brave" end-user :) > > 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 If you can produce a single HTML version of this, that would be good because it would be easier to archive for future reference. This idea has its merits regardless its inclusion into the main LFS book. Thanks! -- James B -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
