Scratchbox2 (SB2) is typically used to create a transparent cross-compiling environment for developing programs and compiling software packages for e.g. embedded devices.

The environment created by SB2 has following differences to the host OS environment:

• First, a virtual file system view is presented to the applications. In practice it means that the file names (paths) which an application uses may be modified before the OS does its operations; applications observe a different file system that what the real file system is. For example, common directories like /bin, /usr/lib and /lib can be changed to point to target-specific directories, which contain files for a different CPU architecture than what the host has.

• Second, SB2 makes execution of foreign binaries completely transparent. Target’s binaries can be executed on the host just as if they were host’s binaries; scratchbox2 will use a CPU transparency method automatically whenever needed, to run them (Qemu is typically used for this).

• Third, SB2 can also virtualize network (TCP/IP) addresses and connections.

The result is that the development machine appears as a virtual target system to the software development tools, and complex tools (like GNU Autotools) can be used directly.

SB2 works by intercepting library calls of dynamically linked binaries using LD_PRELOAD. It uses a flexible and highly configurable rule engine, when deciding what, when, and how to modify parameters of the intercepted calls; this is completely transparent to the users and applications.

SB2 does not need any special privileges or kernel-level services; it is completely based on features that are available for all ordinary users.

Issues to beware in SB2 file mapping:

• Because SB2 needs to map all file accesses done by the C-library, either directly or indirectly, SB2 is dependent on this set of functions. If that set changes, SB2 needs to be updated. Typically these kind of changes aren’t listed in C-library changelogs, finding them out requires extra testing whenever C-library is updated to a version not used with SB2 before.

• Because LD_PRELOAD doesn’t work with statically linked binaries, SB2 cannot work with those when your target and host have the same CPU architecture. When your target has different CPU architecture i.e. CPU transparency is used, this isn’t a problem. Then SB2 just needs to map the small set of CPU transparency method (e.g. Qemu) file system calls. In practice the only real problem so far has been running x86 Valgrind on x86 host as almost all other binaries are linked dynamically.