/mnt/lfs/tools is where the various executable and library components will be
installed, this being the directory that is listed first in your $PATH (for this very reason).
A typical directory structure looks like this:
Code:
/mnt/lfs --+
+-- sources
+-- patches
+-- gcc-3.4.4 {built by tar when unpacking that archive}
+-- gcc-build {created by you}
+-- tools
+-- bin
+-- lib
+-- (and so on...)
Let's say for example that I am about to build
gcc-3.4.4. (Or whatever-version of whatever-product...)
- Starting in /mnt/lfs... (that is to say, "$LFS") Every new build starts there.
- I'll tar ... sources/gcc-3.4.4... to unpack the archive and make the /mnt/lfs/gcc-3.4.4 directory.
- If there are patches, I will now cd gcc-3.4.4 and apply patches from ../patches/gcc-whatever, then cd .. so that I return to /mnt/lfs again. Now that I have fully-patched source in the gcc-3.4.4 directory, I don't have to touch it again. (In fact, I usually write-protect the directory and its contents, just to make sure it remains "pristine.")
- Now I'll mkdir gcc-build ; cd gcc-build, and I'll start with ../gcc-3.4.4/configure --prefix=/tools whatever. I'll do all the work within the gcc-build directory, and aim the final output into /tools.
- If I decide that my installation of gcc is totally-hosed, I can rm -rf gcc-build, remake that directory and start-over with just that step. (Hint: if you're just noodling around, make a bunch of backup-copies of /tools, one for each step as you go.)
The major difference between the stage-5 and the stage-6 builds is that stage-5 executables are built to assume the existence of
/tools and to assume that this directory is first in the $PATH. Stage-6 now builds the objects to be targeted for
/usr, using only the copies found in
/tools (nothing from the host-system), and all dependencies upon
/tools are systematically removed. The
chroot facility is what insulates the host system from being modified as we do this. When stage-6 is finished, nothing should refer to
/tools.
