As described in "Installation and Configuration," the ACCESS Linux Platform is built using the open-source Scratchbox environment. This chapter provides background information about Scratchbox.
About "chrooted" Environments
Scratchbox is a "chrooted" build environment. A chrooted environment is one in which you have changed root to point to a new location. It is basically a sub-tree of the full filesystem tree. When you change the root from / ("slash") to some other path below the root directory, you create a new concept of where the root of the filesystem is. This is not the same as creating a "virtual machine" — you are still dealing with files in your local filesystem tree. But inside the chrooted environment, the path to them starts with /, whereas outside the chrooted environment, the path to them is /path/leading/to/chroot/point.
Scratchbox also uses the fakeroot command for some things. fakeroot runs programs in an environment that looks as if they were run with super-user privileges.
A third kind of necessary fakery for cross-compiling some software is pretending to run test code on the target device as part of compilation configuration. The Scratchbox documentation refers to this as "CPU transparency." This can be achieved either by executing on a connected device (using sbrshd/sbrsh), or via the QEMU emulator. ACCESS Linux Platform's ARM targets are set up to use the qemu-arm emulation.
Special Aspects of the Scratchbox Environment
Scratchbox does more than just running the chroot(8) command would do, which you should be aware of in order to fully understand what the real, non-chrooted paths to things are, and to understand about Scratchbox "targets."
For example, in the Scratchbox environment, you have a $HOME directory, /home/$USER. This directory, and the files and subdirectories it contains, are actually in your filesystem at/scratchbox/users/$USER/home/$USER. This is not simply equivalent to / versus /path/leading/to/chroot/point. Scratchbox includes the idea of a "sandbox" area for each user. This is important to understand, because Scratchbox targets are defined by and for a particular user.
When you are logged in to Scratchbox and have selected a target, if you do a listing on / (ls /); many of the directories you see listed are actually symbolic links to files that really reside under /targets/target-name. This is a critically important aspect of Scratchbox.
Once you have Scratchbox installed, you might want to open two xterm windows—one in which you are logged in to Scratchbox, and the other where you are not—and cd around to different locations in both windows (using the real full path in the non-Scratchbox window), in order to get a good sense of where things actually live.
Scratchbox Targets
A Scratchbox target is basically a configuration for a sandbox. Each target has its own contents for certain subdirectories of the root directory. For example, the contents of /usr will be different for each target. You define a target by specifying certain aspects of it, which toolchain to use, what type of emulation to use (if any), and so on. You can set up a target using the sb-conf command-line tool, or you can use the sb-menu graphical tool. You can define any number of targets.
NOTE: If you do not set (or export)
UML_TARGET in the shell from which you launch the Simulator, the default (assumed) Scratchbox simulator target name is alp-simulator. If you want to be able to launch the Simulator without specifying the target name, then you should name it alp-simulator.
References
For more information about Scratchbox, you can check the following:
- http://www.scratchbox.org/documentation/
This site contains links to documentation on the various aspects of using Scratchbox.
- http://www.linuxdevices.com/articles/AT2051236580.html
This is an introduction to the Scratchbox cross-development from a Linux Devices magazine article.
- http://www.scratchbox.org/wiki/
