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

Jeremy Huntwork jhuntwork at
Mon Apr 18 16:31:06 PDT 2005

Bruce Dubbs wrote:
> Jim Gifford wrote:
>>We will no longer be doing a chroot, since we are going to be booting
>>into a working Linux with enough tools to build what we need, this could
>>be a plus for those who want a more minimal system and an easy way to
>>get rid of the tools directory.
> I have a major problem with this approach being the only one in the
> book.  We are no longer able to build a system remotely.  When we
> brought up anduin, we had (and still have) no physical access to the
> system.  Under the methodology you are proposing, this will no longer be
> possible.
> I don't have a problem with putting this technology into the book, but
> removing substantial functionality is a mistake.

It could be done, but you'd have to deviate, likely, from what is in the 
book. If I'm understanding this correctly, if you are for example, 
building traditional x86 > x86 you could swap out the reboot for a 
chroot. I suppose that would be the case for any matching arch pair.  In 
fact, unless there is any technical benefit to rebooting into a fresh 
kernel before chapter 6 on matching arch pairs, I think I'd rather see 
the book continue to chroot by default and assume that the user is 
building for the same arch, which would remove some of the pitfalls. 
The cross build-method would still be there to abstract the tools from 
the host machine.

Then, for those who need to build from one arch to another, insert 
instructions on building a kernel and booting with tools on said machine.

I guess I'm throwing this out because I really want to avoid those 
pitfalls - which will greatly alter the way all the other LFS projects 
work - Think of how this will affect ALFS and scripted builds in general.

The main purpose I see to build from one arch for another is because you 
lack the tools to build straight from the target arch. (I'm not talking 
about the cross-build method in general - I appreciate very much the 
goal of achieving 'purer' builds and the *ability* to build from one 
arch to another). However I don't think we should by default have the 
build set up in a way that assumes a user is building on two archs.  If 
one of the main reasons for this method is lack of proper hosts for 
building LFS on other archs, I'm anxious to get some cds going for those 
archs, and would gratefully accpet any help in that field.

Hope these comments don't come as a huge shock to the rest of the devs, 
but just reading Jim's comments and thinking on how this will affect the 
shape and direction of LFS and its related projects - I'm thinking maybe 
we need to give some serious thought to avoiding those pitfalls entirely.

Jeremy Huntwork

More information about the lfs-dev mailing list