Planning for Cross-LFS/Multi-Architecture 7.x Release
jhuntwork at linuxfromscratch.org
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
> 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.
More information about the lfs-dev