做Linux嵌入式体系的对常见的几种嵌入式开发环境必定不会默生，由于首要触摸网络相关产品的一些体系规划，因而，将或许用到的嵌入式开发环境扼要总结一下。首要触及下面的几个东东：

emDebian

emDebian依据将Debian用于嵌入式体系的意图而开发。Debian是一个开展很快的项目，在我第一次用Debian时，就再也不乐意换用其它的发布版了，现在我用的Debian现已装置了有两年的时刻了，但现在体系依然是“最新”版别，杰出的在线软件晋级体系是Debian成功的原因之一。现在Debian现已支撑11个体系的体系，包括X86、PPC、MIPS、ARM、SH等（据最近的一则音讯，ARM有或许不再支撑），并包括了很多的软件。这些要归功于Debian的开发团队，正由于有许多人运用和支撑，因而，不是比较偏门的软件，根本上不需求从源码来装置，这也是我喜爱用 Debian的原因之一。

这样好的一个体系，当然有人乐意将其用到嵌入式体系中去。emDebian依据一个很简易的嵌入式体系开发的主意来结构嵌入式体系，即从一个老练的体系中去除不需求的部份（如文档和不需求的东西），精简出一个小的体系，这与下面要介绍的几个东西的主意刚好相反（下面几个都是依据 from scratch 即从无到有，从头构建的方法）。emDebian供给一些东西来帮忙完结从现有的体系或装置包（deb文件，相似Redhat的rpm）中提取需求的东东，并帮忙完结完好体系的构建，当然也支撑穿插构建了，比方你能够在X86 的PC上构建一个依据ARM的嵌入式体系，而整个进程不需求编译任何一行源代码。

水到渠成的，emDebian的重要优势就展现出来了，现在你用的CPU超出11个Debian支撑规模了吗？没有，那么你能够简略的经过 emDebian构建方针体系；你所需求的主体软件在Debian支撑的官方和非官方近2万个软件以外吗？没有，那么祝贺你，明日就能够给老板交工了。当然，关于特定的软件，或许仍是需求从源码来构建，不过相同的，咱们能够将其生成Deb包，然后将装备加到emDebian东西会集，同其它一切软件相同的选取和装备。

emDebian的开展好像不是想像的那么好，现在主页上的新闻更新仍是去2004年的。

buildroot

emDebian实践上并不用定适合于资源十分紧缺的超小型体系，比方只要2M Flash的小型操控体系。别的发行版的软件一般会以通用代码来编译，例如，为了尽或许在各种X86渠道上都能够装置，大大都发行版一般会以i686乃至 i386代码集来编译软件，能够使文件的通用性很强，但CPU的功用却不能发恢到最好（这便是为什么有时会看到一些厂商或爱好者发布PIII、PIV、 athlon等优化体系的原因），这关于嵌入式体系来说也不会是一件好作业。别的，没有源码的操控权，一些需求定制的东西也会变得难以完成，因而，从源码开端构建依然有必要。

嵌入式Linux开发中运用的CPU速度往往向对不会太高，因而，尽或许进步代码的功用就十分必要。一般开发人员应该对该CPU的具体类型有必定的了解，以便启用编译器中对该类型的优化，以ARM为例，咱们能够经过 -march=armv5te 和 -mtune=arm9tdmi 来对代码在ARM9上的运转进行优化。有时这些优化表现出来的功用改善是比较大的，我曾对比过一些杂乱算法的代码优化前后的功用（履行速度），都有必定的提高。别的在PIV上测验过以i686和pentium4对一个语音编码算法进行优化，运算速度竟然进步了几倍。

这种起伏的提高或许仅仅一个特例，这个算法有很多的杂乱浮点运算，运用i386或i686指令集和运用更先进的PIV指令集编译出来的机器代码关于同一个运算的解说或许选用彻底不同的指令来完结，因而功用提高较大就家常便饭了。相同这种代码，在ARM上经过ARM4和ARM5来优化后在ARM9上运转，却没有那么大的提高。看来对CPU的必定了解也应该是嵌入式体系软件规划者应该具有的才能。

那么又怎么操控可履行文件的巨细呢？除了却除软件中不需求的部份外，咱们还应该考虑软件所引证的库文件。GNU的Glibc是一个十分宠大而完好的库，至少关于嵌入式体系来说，其体积显得过于大了一些。uClibc的提出较好的处理了这样一个问题。uClibc尽或许的兼容Glibc，大大都运用程序能够在很小或彻底不修正的情况下就或许运用uClibc替代glibc。经过uClibc来替代Glibc，能够在不改动运用程序功用的前提下，大大削减发布文件的巨细，不管运用程序以静态链接来编译，仍是以动态链接方法编译。

不过运用uClibc替代并不是简略的设置一两个参数就行了，一般需求运用一个不同的东西集（gcc/binutils等）来编译代源码。手艺的结构这样一个环境，关于大大都一般程序员来说，不用定是一件很简略的作业，因而，uClibc的开发者创造出一个叫做buildroot的东西集。 buildroot将主动结构编译依据uClibc代码的东西集和uClibc库，并供给一个可装备的结构和一些构建一个根本体系的装备文件。用户只需求经过装备菜单挑选了相应的方针软件，buildroot就能够从构建根本东西集开端，一向到终究构建出方针体系所需求的东西，如嵌入式体系常用的依据 ext2的initrd，jffs根文件体系，紧缩的根目录树等，这些代码都是依据uClibc而不是体系的Glibc的。Buildroot对主机体系的要求较小，一般只需求主机体系供给足以构建东西链(toolchain)的东西，如gcc/binutils等，当东西链编译完结后，对方针体系需求的源码的编译进程与主机体系的开发东西集根本上就没有什么联系了。因而，不同的主机假如能够经过第一步，编译完结东西链，那么编译出来的方针体系的履行代码就能够简直不存在由于体系引起的差异。这样，开发人员就或许在各自喜爱的Linux发行版上进行开发，而不用忧虑呈现什么兼容性问题。#p#

uClinux

uClinux与emDebian至少有两个重要的差异，第一是构建方法，前面现已说到过了，uClinux归于 from scratch 一类的。另一个不同的当地，uClinux是支撑不在emDebian支撑的11种CPU的，当然，这个说法不是很恰当，正确的说法是uClinux支撑那些不具有MMU单元的CPU体系。uClinux的第一个意图是支撑MC68328芯片，现在现已能构支撑更多的CPU，如Intel i960，ARM等。不过，uClinux的主体开发团队现在现已不再支撑ARM了，还好 Samsung 的 Hyok S. Choi 接过了接励棒，Linux 2.6版别的补丁能够在 uClinux/ARM2.6 找到。

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的主机上正常的运转！

【修改引荐】

1. uCLinux嵌入式体系开发进程操控
2. 依据TinyXml的嵌入式Linux
3. KVM在嵌入式Linux上的移植
4. 嵌入式Linux体系下的网页浏览器WebKit
5. 嵌入式Linux中的进程同步无竞赛态读写