Scratchbox
Scratchbox 的故事要从buildroot讲起(这不一定是scratchbox开发者的故事，只是依据我个人的认识)。buildroot可以从头开始，先构造编译器和基本开发环境，然后根据用户配配置构造一个适用于目标平台的根文件系统。这个文件系统可以有许多用法，例如，做为initrd或通过NFS输出给目标系统使用。为了减少交叉编译软件带来的麻烦，可以配置buidroot创建一套目标系统的编译环境(Gcc、binutils、lib等)，这样用户可以通过这个基本文系统在目标系统上直接本地编译软件。如果目标系统性能足够的话，buildroot的任务到此就基本结束了。对于嵌入式系统的开发者来说，在目标系统上直接编译代码却不一定都能够实现，因为多数情况下，我们的目标平台处理器性能并不会那么高，这样，我们就不得不面对一个两难的选择：
继续通过buildroot编译其它的软件，性能会高许多，但每个软件都需要进行交叉编译相关的改造；
在目标平台上编译软件，对于只有几十或几百兆的低性能核来说，编译一个核心可能会让你等上半天的时间；
有没有好的办法解决性能和交叉编译的问题呢？先分析一下通过buildroot交叉编译不能解决的问题。Buildroot只在一定程度上对目标平台进行了模拟，但仍有一些是无法实现的，例如，当目标平台不同于主机平台时，不能生成并运行目标平台的中间代码。这样，许多通过autotools (autoconf/automake)配置的软件就可能会出现问题。例如，configure 脚本有时会生成一些中间代码，并试图运行以确认开发环境中是否存在某个库文件或头文件，对于在X86上编译基于uClibc X86目标平台代码可能不会出现问题，但如果目标平台是X86以外的平台，编译就可能会中断；又如，configure脚本确认编译器是否工作，会试图编译一个包含空的主程序的代码并运行，实际一个可运行于目标平台的 a.out 确实生成了，也可以正常运行于目标平台，但是这个测试会因为 a.out 被运行在主机系统上而错误的中断。这些问题一些被 buildroot 通过补丁或复杂的 configure 参数解决了，某些中间执行文件，则通过HOSTCC(主机上的CC)来生成并运行以生成最终文件。目前buildroot包含的软件或多或少都会有一些这样的补丁，而且开发者一旦深入到对软件的定制，就会不停的被这些问题所困扰。
Scratchbox相比于buildroot有几方面的改进：
运行于 chroot 的环境，完全独立于主机，编译过程将基本与主机系统无关(并且scratchbox修改了一些库，使得普通用户可以chroot到编译环境中，并且多个用户可以同时使用一套Scratchbox开发套件和完全独立的用户资源)；
透过qemu模拟运行或sbrsh解决中间执行文件或类似configure测试文件运行的问题；
对(chroot后)的系统进行修定，达到足以欺骗大多数软件的效果，这并不是指的让软件可以不进行改造就可以 交叉 编译，而是使软件 误认为 这就是在目标平台上编译；
不过 Scratchbox 目前还只能编译 ARM 和 x86 的代码，不能支持 buildroot 所支持的 ppc、mips等。
本文不详述每一种环境，因此各个软件都只是点到为止(虽然可以讲得更详细一些，但这些内容还是独立出来比较好一些)，不过这里还是引入一个很简单的示例，根据 scratchbox 网站上的文档，安装完成后，进行简单配置就可以使用了(Debian用户的安装可以更简单，因为该站提供Deb包，直接apt-get就行了)。通过 /scratchbox/login 登入开发环境，通过sb-menu配置一个基于 ARM 的环境(其中 Select CPU-transparency method 选qemu不要先sbrsh)，然后写一个 helloword.c，编译并运行之。通过ldd可以看到，在没有任可改动的情况下，顺利的生成了ARM ELF，但在 scratchbox 里却可以在X86的主机上正常的运行！
[sbox-redice: ~] > gcc -o hello hello.c
[sbox-redice: ~] > file hellohello:
ELF 32-bit LSB executable, ARM, version 1 (ARM),
for GNU/Linux 2.0.0,dynamically linked (uses shared libs),
not stripped[sbox-redice: ~] >
./hellohelo world![sbox-redice: ~] >
文章来源于领测软件测试网 https://www.ltesting.net/
