TheOldFellow wrote: > Finally, a note about Ryan's scripts. They are, no doubt, extremely > clever. This is the problem. I will not expend the energy to > understand someone elses complex script.
Well, I decided I'd try anyway. This is the result. I find myself completely baffled about HOW the cross compiler is built. Can someone point me at a (short) tutorial. R. Anyway, for what it's worth: The Ryan Oliver Cross-Built LFS Method. A short introduction (just to see if I've got it) By TheOldFellow 2005-04-19 What's all this then? --------------------- For the past year or so, since the Pure-LFS method of building the LFS toolchain was invented by Ryan Oliver and Greg Shafer, Ryan has been working on a new toolchain build method that works for situations where the host machine and the target machine are of different architectures. Although Ryan has dropped a lot of hints along the way as to how this all works, and even published his scripts, it's not clear, as I start to write, at least, to me how every nuance behaves to achieve the objectives. So I thought that rather than moan about it, I'd write it up. Hopefully, Ryan or someone else will tell me where I'm wrong, and add the bits I've obviously not noticed. Necessarily much of this is plagiarism - I acknowledge everything I borrow as being the intellectual property of it's originator. Objectives ---------- The objectives of the method are as follows: At no point do any host system headers or libraries pollute anything in the new system, not even the temporary toolchain used to build the final result. No reliance on the running kernel version while building the temporary toolchain. This means that the architecture of the running kernel can't influence the result. Separation of the host tools (i.e. initial compiler/binutils) which are linked against the host system libraries from the tools that will be used to produce the target system. That is, the tools that are used to build the target system are linked against a glibc built specially for that purpose. This separation means that there is no need to edit the specfiles or interfere with the normal operation of the linker (as is done in the current Pure-LFS derived LFS). And there is no need for the keep binutils source directory around. The method produces 2 separate toolchains early in the build, one is a cross-compiler (use to build things on the host system for the target system), the other is a target native compiler (which is used to build the target system on the target system). This also has the advantage that it's possible to backtrack to solve problems, if, for instance, you want to try a novel configuration option or a patch, or just to correct a mistake. It's possible to build multi-lib targets from any host (or LiveCD). For instance, building a bi-arch x86_64 from a x86_32 host. But the major advance over the current method (Pure LFS) is that this method supports cross-platform builds, uni-arch or multi-arch, and those with difference glibc extensions, e.g. nptl or linuxthreads threading. Overview -------- The method consists of a number of phases, each separate and self contained: 1.Building a good set of host tools. It's important that the tools used in the later stages can rely of the toolchain used to build them, so the method starts by ensuring the versions and capabilities of the host toolchain to be used. These tools are help completely separately from the host's own toolchain, and are built as an ordinary user. 2.Building a set of tools designed to run on the host producing code to run on the target. This is not just the cross-compiler, but is a fully bootable system with the option to build extra facilities, such as networking and ssl/ssh. Of course, it's designed to boot on the target architecture. 3.Either having booted the system built in 2 above on the target architecture, or having chrooted into it (of course, this later implies that target=host), the final system is built using similar instructions as in chapter 6 of the LFS book today. Note, that each phase is self contained, only the output of the phase is used in the subsequent phase, so if you discover a need in phase 3 for a tool that you failed to build in phase 2, you can return easily to phase 2 and build it. Details ------- Phase 1 Building a consistent set of host compilation tools. There are a number of tools that are needed in Phase 2, and they must perform as we expect them to. The tools may or may not exist of the host, and if they exist they might or might not be the versions we require. This simplest solution is to build a fresh set, using versions known to have the correct properties. Phase 2 can then be done with this consistent set of tools higher in $PATH than the equivalents on the host. The order of building is designed to minimise the possibility that the host's libraries of include files will impact the tools. The tools are built as an ordinary user, and none is built setuid etc.. Phase 2 Building a bootable system for the target system. Now we have a complete and consistent set of host tools, we build a cross-compilation system and then use that to build a bootable system for the target architecture. Note that the target architecture can be the the hosts architecture, but it could also be something exotic, the only requirement is that gcc supports it. To build a cross compilation system we will need to use headers (include files) that are appropriate for the target system. 1.Install a set of kernel headers for the target system's kernel. 2.Build binutils, adding the --host and --target configure options to force configure to build a cross-compilation system (e.g. The linker runs on the host, but expects object files in target format, and creates executables for the target) 3.Install glibc headers by configuring glibc with --host and --build options, sourcing the kernel headers and binutils tools from this phase and then running: make install-headers Then we add a set of headers for the threading library, since gcc needs them for thread support. 4.Now we build the cross compiler gcc by passing the configure option --host and --target. +++++++ I don't understand all the stuff about start files, and what about specfiles ? - someone please help. This must be the clever bit! +++++++ 5.Finally we build a target glibc and then enough of a system to boot using the cross compilation system we've just made. Phase 3 Building a The target system on the target system. Having booted the on target system, we use the toolchain built for the target in Phase 2 to build a complete system. The only deviation from the current lfs book is to rebuild the ld executable as soon as a new not-cross-compiled glibc is built. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
