几种Linux下嵌入式开发环境的简单介绍

　　uCLinux之前仅是核心的一些补丁，后来发展成为一个包括核心、库、应用程序、工具和编译相关的配置文件的一个集成开发环境。与 buildroot不同的是，uCLinux不编译目标系统的工具集，也就是说，相应的编译工具应该提前安装好。如，对于arm来说，需要先安装ARM交叉编译器。uCLinux的编译器也需要一些补丁，其中比较重要的两个方面主要包括：

　　用于生成FLT文件的补丁：由于MMU的关系，uCLinux不支持ELF可执行文件，这个补丁主要包括bin2flt工具包和一个ld的wrapper脚本等，用于(透明于用户)生成FLT文件;

　　用于支持XIP(Execute In Place)的补丁：这个补丁需要对gcc进行一些小的修改;支持XIP主要是为了解决小内存环境中运行的问题。

　　XIP不一定适用于每种应用环境，对于内在要求特别严格的系统来说(空间第一位，如手机要求使用片内RAM)，可以通过将核心和应用程序编译为 XIP支持，然后直接在Flash上运行，内存仅用于运行时数据;而对于性能要求为主的系统(如高速网络处理器)，则不能因为节省一点空间而使用XIP将程序直接在Flash上运行，这样可能会降低指令的读取速度而影响系统性能(但仍然可以使用 XIP，使程序的多个实例在内存中共享代码空间，以后详细说); + FLT可执行文件支持动态链接库(目前仅m68k支持，参见 uCdot: Shared libraries under uCLinux mini-HOWTO)的补丁;

　　uCLinux的编译过程大致是，首先，通过可视配置界面(menuconfig/xconfig)选取Vendor和board(实际上是选择了一些配置文件和产品相关的文件)，然后根据选择构造一个适用于target的开发环境，如生成头文件和需要的库文件(uClibc、glibc或 uC-libc 以及其它一些库)，然后编译核心、库、应用程序，最后将所有的输出安装到romfs目录中，根据需要生成目标平台需要的映像文件(如： romfs.img、Linux.bin、rootfs.gz等)

　　由于一些过程细节被隐藏起来，uCLinux现在的编译过程方便到只需要配置一下(make menuconfig)，然后 make 就可以直接获得最终输出。不过这反倒成为一些初学者学习的一个麻烦，本文完成后，根据对本文的反馈，将进一步对uCLinux进行详细介绍。

　　总的来说，目前的uCLinux是一套主要用于无MMU核(但不限于此)的嵌入式Linux集成环境，也是一个非常好的 Linux from scratch 的示例。抛开其MMU相关的补丁，uCLinux也可以作为一套用于包含MMU系统的集成开发环境，Snapgear 就是一个很好的例子。实际上，我们可以从官方的uCLinux源码就可以直接编译一个支运行于X86的uCLinux。

　　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: ~] >