Jeremy Utley wrote these words on 04/18/05 23:14 CST: > Randy McMurchy wrote: >>Please, Jim, for me and I'm sure there are others that want to know >>the same thing, can you explain *in a technical manner* how the >>toolchain could be any "cleaner"? > > A simple example will document this clearly. Take building LFS on a > Fedora core release. In the past, we had issues with our chapter 5 > glibc build picking up the presence of SE-Linux in Fedora core 3, which > caused the chapter 5 glibc to also enable SE-Linux. But, once we got > into chapter 6, it caused the glibc build to barf, because the headers > for selinux were no longer present. This build process completely > eliminates that situation. Anything that links to the host does NOT end > up at all in the $LFS tree - the 2 packages which are linked to the host > (cross-gcc and cross-binutils) are prefixed to the build user's home > directory.
Thanks for the input, Jeremy. Though I still don't understand how this relates to my question. My question is about the finished binaries. In the example you give above, it doesn't have anything to do with the finished product. It only has to do with failures *getting* to the final product. I realize that the process as Jim outlined eliminates problem hosts. But what about for hosts that can build without issues? The need to reboot and build from the console is an overwhelmingly big new difference. To the point that I would have to find a different build method than what Jim described. I have build scripts, but I don't run them. I cut and paste them. I wish to examine the output of each command before continuing the build. Especially with new versions of LFS. Sure it takes me a bit longer to do it this way, but everything is checked out as I go along. I don't have to go back and figure out what caused something to fail along the way because of a problem 6 packages ago. I'm just asking questions because it seems to be a huge new difference in the build method. Nothing of which benefits me. Sure this sounds as if I'm disappointed that LFS doesn't cater to my needs, but our current build method works well, for the large majority of readers. Shouldn't we continue to cater to the large majority. I liked Jeremy H's idea about a split in the book when it comes time to reboot or chroot. Shouldn't we investigate to see if something like this is feasible. That's all I'm asking. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 23:21:00 up 16 days, 22:54, 3 users, load average: 0.09, 0.11, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
