scratchbox代替交叉编译工具

转载

Scratchbox
的故事要从buildroot讲起（这不一定是scratchbox研发者的故事，只是依据我个人的认识）。buildroot能从头开始，先构造编译
器和基本研发环境，然后根据用户配设置构造一个适用于目标平台的根文件系统。这个文件系统能有许多用法，例如，做为initrd或通过NFS输出给目标
系统使用。为了减少交叉编译软件带来的麻烦，能设置buidroot创建一套目标系统的编译环境（Gcc、binutils、lib等），这样用户能
通过这个基本文系统在目标系统上直接本地编译软件。如果目标系统性能足够的话，buildroot的任务到此就基本结束了。对于嵌入式系统的研发者来说，
在目标系统上直接编译代码却不一定都能够实现，因为多数情况下，我们的目标平台处理器性能并不会那么高，这样，我们就不得不面对一个两难的选择：
   1.   继续通过buildroot编译其他的软件，性能会高许多，但每个软件都需要进行交叉编译相关的改造；
2. 在目标平台上编译软件，对于只有几十或几百兆的低性能核来说，编译一个核心可能会让你等上半天的时间；
有没有好的办法解决性能和交叉编译的问题呢？先分析一下通过buildroot交叉编译不能解决的问题。Buildroot只在一定程度上对目标
平台进行了模拟，但仍有一些是无法实现的，例如，当目标平台不同于主机平台时，不能生成并运行目标平台的中间代码。这样，许多通过autotools
（autoconf/automake）设置的软件就可能会出现问题。例如，configure
脚本有时会生成一些中间代码，并试图运行以确认研发环境中是否存在某个库文件或头文件，对于在X86上编译基于uClibc
X86目标平台代码可能不会出现问题，但如果目标平台是X86以外的平台，编译就可能会中断；又如，configure脚本确认编译器是否工作，会试图编
译一个包含空的主程式的代码并运行，实际一个可运行于目标平台的 a.out 确实生成了，也能正常运行于目标平台，不过这个测试会因为 a.out
被运行在主机系统上而错误的中断。这些问题一些被 buildroot 通过补丁或复杂的 configure
参数解决了，某些中间执行文件，则通过HOSTCC（主机上的CC）来生成并运行以生成最终文件。目前buildroot包含的软件或多或少都会有一些这
样的被丁，而且研发者一旦深入到对软件的制定，就会不停的被这些问题所困扰。
Scratchbox相比于buildroot有几方面的改进：
1.   运行于 chroot 的环境，完全独立于主机，编译过程将基本和主机系统无关（并且scratchbox修改了一些库，使得普通用户能chroot到编译环境中，并且多个用户能同时使用一套Scratchbox研发套件和完全独立的用户资源）；
2. 透过qemu模拟运行或sbrsh解决中间执行文件或类似configure测试文件运行的问题；
3. 对(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的主机上正常的运行！