Aboriginal Linux: We cross compile so you don't have to.

===============================================================================
--- What is it?

  Aboriginal Linux provides virtual Linux images you can boot under QEMU,
  within which you can compile and test any software you like.

  The build scripts automatically create cross compilers and bootable system
  images for various targets, such as arm, mips, powerpc, and x86.  You can
  download the resulting binaries from the website if you don't want to bother
  compiling them yourself.

  The system images provide minimal native development environments which you
  can boot under an emulator (or on real hardware if you have it) to compile
  code natively.  This includes a full native compiler (for both C and C++),
  and the (optional) ability to run the cross compiler on the host (via distcc)
  to speed up the build without reqiring the packages you're building to
  know anything about cross compiling.

--- How do I try it out?  (Quick start.)

  - Download a system-image tarball for a target that interests you.

  - Extract it and cd into the directory.

  - Run the "./run-emulator.sh" script.

    After the kernel boot messages and the output of the init script, you
    should get a shell prompt from inside the emulator.

    - Run "cat /proc/cpuinfo" to confirm the emulator is running.

    - Run "gcc -lpthread /usr/src/thread-hello2.c" (and run the resulting
      "./a.out" file) to confirm the native toolchain works.

    - Type "exit" when done.

--- What's this "target/host" business?

  The host is the system the emulator runs on.  The target is the virtual
  system running inside the emulator.

--- Do I have to care about cross compiling?

  No, you don't.  Just boot a system image under QEMU and build packages in
  there (or find some real hardware to boot your root filesystem on, and note
  that the distcc acceleration trick still works in that context too).

===============================================================================
--- What's the purpose of this project?

  Aboriginal Linux serves two purposes: practical and educational.

  The practical purpose is to provide emulated native development environments
  for every target QEMU supports.  This avoids the need for cross compiling
  by allowing you to download a bootable system image and build natively within
  it.

  Aboriginal Linux is also designed to document how to bootstrap minimal
  Linux development environments for a new target.  The build is a series of
  bash scripts, with lots of comments explaining what they do.  These scripts
  show how to make a cross compiler (and optionally how to use it to make
  a better cross compiler), how to build a root filesystem and native
  development tools, and how to package and boot the result under an emulator.
  If you don't know how something works, read the script.  If something's
  unclear, ask about it on the mailing list.

===============================================================================
--- How do I use Aboriginal Linux?

To download prebuilt binaries for each target:

    http://landley.net/aboriginal/downloads/binaries

  The "system-image" tarballs are what you need to boot a virtual target
  under QEMU.  They contain a squashfs root filesystem (including a native
  compiler toolchain), an appropriately configured Linux kernel, and shell
  scripts to invoke the the emulator with appropriate arguments.

  The cross-compiler tarballs are useful for accelerating native builds via
  distcc (using the dev-environment.sh script, explained later in this file).

  If you want to install Aboriginal Linux on real hardware (or set up a
  chroot), the root-filesystem and native-compiler tarballs are probably
  what you want.  (You may need to provide your own kernel and bootloader.)

  Various statically linked binaries are also available for each target
  (busybox, dropbear, strace...) which can be used on any appropriate target,
  not just with Aboriginal Linux.  Just download them (with wget), set the
  executable bit (chmod +x), and run them normally.

To use the build scripts to build your own binaries from source:

  Download the most recent set of build scripts from:

      http://landley.net/hg/aboriginal/archive/tip.tar.bz2

  To list available targets, do:

      ./build.sh

    We'll use "mipsel" (mips little endian) in the following examples.  Replace
    that with the target you're interested in from this list.

  To compile a system image (and all prerequisite stages) for a target:

      ./build.sh mipsel

    This calls the other stages (from download.sh through system-image.sh)
    in order, to produce a bootable system image.  The downloaded source
    tarballs are kept in the "packages" directory, all other output goes into
    the "build" directory.

    For each target, the build tars up the various build stages
    (cross compiler, native compiler, root filesystem, etc).  The last stage
    is a bootable system image configured for use with the emulator QEMU,
    in this case build/system-image-mipsel (with a corresponding tarball
    version for posterity).

  To build every supported target simultaneously (in parallel, using around
  2 gigabytes of ram and maybe 20 gigabytes of disk space):

    FORK=1 sources/more/buildall.sh

  The file "configure" contains several environment variables you can set to
  control the behavior of Aboriginal Linux, and has comments documenting what
  the all doo.  (You can persistently set them by altering this file, or
  set them temporarily in your environment before running a build.)

  For more information, see the README file in the download directory.

    http://landley.net/aboriginal/README

To boot a system image under QEMU:

    cd build/system-image-mipsel
    ./run-emulator.sh

  Each system image contains a root filesystem image (for use as a virtual
  hard drive), a kernel configured for use with QEMU, and a run-emulator.sh
  shell script to boot those two files together under QEMU.

  After the kernel boot messages scroll by, you should have a shell prompt
  inside qemu.  Try "cat /proc/cpuinfo" to confirm it's not the same as your
  host.  Try "cc /usr/src/hello.c" to build some of the included example
  code.  Type "exit" to shut it down.

  The environment variable QEMU_EXTRA can supply extra command line arguments
  to the emulator.  The environment variable KERNEL_EXTRA can supply extra
  command line arguments to the Linux kernel running under the emulator.

To set up a more powerful virtual build environment:

    cd build/system-image-mipsel
    ./dev-environment.sh

  The dev-environment.sh script is a wrapper around run-emulator.sh that does
  two things to give you a better development environment:

  1) Make sure the emulator allocates at least 256 megs of physical memory.

     Set the environment variable QEMU_MEMORY to the desired number of
     megabytes if you'd like more.  (Note that some targets can't support more
     than this, in which case the emulator will print out an error message
     instead of launching the virtual system.)

  2) Mount lots of writeable space on /home in the virtual system.

     The script creates a 2 gigabyte sparse file on the host named hdb.img,
     formats it ext3, and tells the emulator to mount it on /home.

     This keeps the existing hdb.img if it already exists, so its contents
     persist between dev-environment.sh invocations.  If you need more space
     than 2 gigabytes, you can supply your own hdb.img.

  2) Hook up distcc to call out to the cross compiler on the host, to speed
     up your builds by moving the heavy lifting of compilation outside the
     emulator.

     This only happens if you have both distccd and the appropriate cross
     compiler is in your host system's $PATH.  (Install distcc on the host,
     and downloaded the appropriate cross compiler tarball and add its "bin"
     subdirectory to your $PATH).  If both are available, the script launches
     a private instance of distccd and configures the virtual system to use
     distcc to call out to the cross compiler.

     The reason this doesn't re-introduce the complexity of cross compiling is
     because the build still only has a single context, and thus behaves like
     a fully native build.  Configure, make, preprocessing, and linking all
     still run natively inside the emulator.  Using distcc means the build
     sends preprocessed source out through the network and gets compiled .o
     files back, but it neither knows nor cares whether the servers it's
     connecting to are cross compiling or native compiling, as long as they
     produce the right output.

To automatically build more software packages inside the emulator:

    ./native-build.sh mipsel hello-world.hdc output_dir

  Aboriginal Linux supports automated builds via a two stage process.
  Get a control image, then launch a system image with it.

  1) Obtain a control image.

     The scripts in sources/native-build (such as hello-world.sh and
     static-tools.sh) create build control filesystem images.  For example,

       sources/native-build/hello-world.sh hello-world.hdc

     These are squashfs formatted filesystem images that contain extracted
     source code, plus a shell script to build that code and upload it to
     the host (via ftp).

     You're encouraged to create your own control images using the existing
     native-build scripts as a model.  The images the existing scripts create
     are available in the downloads/binaries directory.

  2) Use native-build.sh to launch that control image under the emulator.

     This is another wrapper script, this time around dev-environment.sh
     (which is in turn a wrapper script around run-emulator.sh).

     This wrapper does two things:

     1) Launch an ftp daemon, and inform the virtual system where to find it
        via the FTP_HOST and FTP_PORT environment variables.  This lets the
        emulated target system upload files to the host via "ftpput".

        Launching an FTP daemon requires busybox in the $PATH on the host, and
        uses the busybox nc and ftpd applets to provide an ftp server.  (We
        can't use an arbitrary one on the host because different ftp daemons
        understand different command line options.)

        You can set the environment variables $FTP_HOST and $FTP_PORT to point
        it at an existing FTP daemon.  If either variable is set, the script
        won't launch a new FTP daemon.  (Note that the default value for
        $FTP_HOST is 10.0.2.2, which is QEMU's tunnel through to the host
        system's 127.0.0.1.)

     2) Launch the emulated development environment with a control image, to
        be mounted on /mnt by the init script.

        Basically this adds "-hdc filename" to the QEMU_EXTRA environment
        variable to supply a third virtual disk to the emulator, then calls
        ./dev-environment.sh as normal.

        The Aboriginal Linux init script (sbin/init.sh) checks for the
        existence of /mnt/init, and runs that if it exists instead of
        providing an interactive shell prompt.  (It waits three seconds for
        you to press a key if you do want a shell prompt, in which case you
        can launch /mnt/init yourself when you're done.)

        When /mnt/init exits, the virtual system shuts down and exits the
        emulator, just like typing "exit" at the interactive shell prompt.

To cross compile stuff on the host:

  If you already do cross compiling, and would like to use this project's cross
  compiler to build something else, just add its "bin" subdirectory to the
  $PATH, and use the build tools prefixed with the target name:

    PATH=$(pwd)/build/cross-compiler-mipsel/bin:$PATH
    mipsel-gcc -static hello.c -o hello
    qemu-mipsel hello

  If you don't do cross compiling already, this project isn't going to teach
  you how, and in fact recommends you just don't go there.  We cross compile
  so you don't have to.