Planning for Cross-LFS/Multi-Architecture 7.x Release

Jeremy Utley jeremy at jutley.org
Mon Apr 18 21:44:55 PDT 2005


Randy McMurchy wrote:

>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.
>  
>
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.

>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.
>  
>
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.

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-



More information about the lfs-dev mailing list