Some initial thoughts
Once we have the native compiler, we can build applications. We have actually started doing that - if you follow the NativeCompiler steps, you actually have started to build the applications when you did Chapter 6. If you follow BuildingTheToolChain steps, you do that when you build the Final Native Compiler step. Those are the first applications get built and installed.
Before starting to build applications, consider what you plan to do about PackageManagement, that is, how to install / uninstall / upgrade packages now and in the future. If you are not sure what to do, rather than falling into analysis paralysis; just install packages in the way that you can retrieve it later and store them in a tarball (there are always ways to convert the tarball into different package format later). There are many ways to do so:
make install DESTDIR=/xxxwhen available (and collect the package build output when done)
- build the software in a sandbox
- or save your effort and use some kind of software that can capture installation output - like checkinstall or paco.
I used paco myself. In addition to capturing the packages for later use,
paco gives me a handy undo feature. If I install a wrong package, I can
easily remove that installation by using
paco -r . Some packages provides
make uninstall for the same purpose but most don't; using paco I have this
extra safety measure.
What applications to build?
And the answer really depends on you.
If you want to build GUI / graphical applications you will need to build at least X libraries and some sort of toolkits (GTK, Qt,FLTK, etc) to begin with. If you want to build only command line applications (servers: database servers, email servers, etc) then you don't need any of these and can go straight to building the supporting libraries: PAM, openldap, etc.
How to build them?
Track the dependencies. Built the applications/libraries that the main application requires them, before building the main application. E.g. To build gnumeric (a popular spreadsheet application), you need to build GTK first. To build GTK, you need to build a bunch of other libraries like ATK, Pango, Cairo, Harfbuzz, etc. Many of these tools ultimately depends on X libraries. So in this case, you start by building X libraries (even though you don't plan to run an Xorg server at all).
If that sounds complicated, that's because it is. Many modern open source applications leverages existing open source libraries rather than re-inventing the wheel, which is good for efficiency purposes but complicates building them.
If you are new to building applications, try to find a known working
recipes to build them. There are many good sources; you can look at
Beyond Linux From Scratch (BLFS) or
the build scripts from Slackbuilds, or
similar build scripts from Arch Linux or Gentoo. These recipes tell you
what are the dependencies, what are the correct
configure flags you need
to use, etc. Of course you can always experiment - not all dependencies are
mandatory (some can be removed), and you can always change the flags and see
what's the effect.
How FatdogArm applications are built
I use BLFS as a reference for the build recipes; falling back to building on my own if it is not in BLFS. I only use Slackbuild when I can't get the application to build in any other way or involves too many unnecessary tricky stuff that has been solved by others (e.g. building localised Seamonkey).
Since I plan to build a desktop, I started with building X Libraries and Xorg server ( BLFS Chapter 24. X Window System Environment )- up to the point I've got twm up and running.
When that was completed, I built GTK2 libraries, again following BLFS
(actually there isn't much of build instructions, most instructions are just
./configure --prefix=/usr --sysconfdir=/etc localstatedir=/var --disable-static
but GTK2 has a load of dependencies and BLFS explains it pretty well.
After GTK2 was ready, I build the desktop environment which depends on GTK: window manager (openbox), panel (lxpanel) and file manager (ROX Filer), plus minimal utilities that will help me build more stuff, like text editors (geany, leafpad) and terminals (rxvt-unicode).
More libraries after that (alsa libraries so that apps can play sound later on), followed by the real applications (seamonkey web browser, abiword, gnumeric, mtpaint, osmo, etc) and Fatdog/Puppy Linux tools (Xdialog, dialog, gtkdialog, gtk-server, etc).
See my progress on RoadMap.
Questions and Answers
Question: I'm not a fan of native compiling. My target CPU and/or development board is too weak to do any sort of compilation on it. Can I build applications using the cross-compiler? After all, you built the native compiler using the cross-compiler, and it isn't the only thing that the cross-compiler is good for, is it?
Answer: As said elsewhere, it is possible to build everything by cross-compiling. Even Mozilla provides documentation on how to cross-compile their flagship browser.
But cross-compiling is hard - not many packages are designed for cross-compilation; and even those which are, there are many problems requiring extensive patching or pre-configuration of the build system.
If you want to see an example of this, just look at CLFS Chapter 6 (this is the chapter that builds native tools using the cross-compiler - thus the cross-compilation phase). There aren't many packages built in Chapter 6, only the most basic ones. And you can already see the amount of patching and preparation required to get them to work correctly.
Thus, the previous step of getting the native compiler; with the idea that we will build all the applications natively. The major downside of doing this, unless you own a relatively recent quad-core CPU with 2GB RAM (and I would say even with the quad-core CPUs), is that it is extremely slow. It took me 15mins to build the naked gcc on my x86_64 laptop; the same process took 3 hours on ARM. It took me 2 hours to compile Seamonkey browser on my laptop, and 18 hours on the ARM.
The better way of doing things would be to use Aboriginal's method (configure on native compilers; but build using cross-compilers) and I will cover it in this article.
Question: My application is large and have a lot of dependencies. This isn't compatible with my goal of creating feather-sized distribution. How do I trim down the size?
Answer: The answer is: don't. At least, not yet, not until you're ready. Fidgeting with application size is considered as optimisation, and premature optimisation is evil , said one of the computing founding fathers: Donald Knuth (or if you need a newer reference, how about this from Michael Abrash - yes this is the guy who originally wrote Quake, Windows NT 3.1 graphics stack, the Intel Larrabee GPGPU architecture, and now works at Valve).
The main tenet is - don't optimise until you know what to optimise. Optimising for size most of the time also means sacrificing features. So build the application the way it is designed first, make sure that it works, use for yourself, and only after that you know what you can or are willing to remove.