Randy McMurchy wrote:
Jeremy Utley wrote these words on 04/18/05 23:14 CST:The final result of the binaries is immaterial, in this case. That issue exposed a flaw in our current build process, exposing that our host can still affect the build inside the chroot, even with the PLFS stuff that was developed for LFS 5. This is something that needs to be fixed.
Randy McMurchy wrote:
Please, Jim, for me and I'm sure there are others that want to knowA 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.
the same thing, can you explain *in a technical manner* how the
toolchain could be any "cleaner"?
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.
And that need only arises if you are building from a different arch from your host. For example - my current PPC machine is a terribly slow 120 Mhz 604 processor. Building current LFS 6 on that machine takes nearly a week of work to get done. What if I could build a large portion of that on my nice fast X86_64 machine? That would be a good thing. For you, the situation is different - you build strictly on x86-class machines - there would be no need for you to reboot, as was pointed out by Ryan. You could simply chroot into $LFS and continue on your way.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.
There's a lot of plusses to this build, and very few downfalls, when you really sit down to think about it. Mentioning the need for the reboot was a good thing, but it's important to know WHY that becomes essential - because if we're building for a different arch, the binaries we create as part of the initial tools will not run on the host. If those binaries will run, there's absolutely no need to reboot.
Hopefully this clarifies things.
-J- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
