先说两句废话为和我以前一样对操作系统（尤其是嵌入式操作系统）迷惑的弟兄解释些概念。因为总是有人在问是不是一定要用操作系统，我的CPU能不能移植操作系统，可以移植什么操作系统，有了操作系统可不可以运行某些程序。 M开发论坛
从我的个人经历来讲，这其实就是许多硬件出身的弟兄对操作系统这个东西有神秘感（和我一年前一样）。说白了，操作系统就是一段设计非常巧妙的程序，和你自己的程序从本质讲没有区别，于是，以上问题转为，我是不是一定要用这段程序，我的CPU能不能运行这段程序，可以跑什么样的程序。这个程序可以跑，调用这个程序接口的另一个程序能不能跑！
答案也就变得简单，操作系统对任何一个CPU都不是必须的（对嵌入式系统更是如此），你可以自己编些程序在没有操作系统的PC裸机上跑（BIOS就是这样的），像玩C51一样，（虽然奢侈的让人有些心痛），或者移植UCOS到上面。另一方面，现代操作系统大多需要一些硬件的支持，（像保护模式的实现），反过来说，高端CPU中专门有针对支持操作系统的体系结构，这样，许多操作系统的实现是挑剔硬件平台的。其实其它程序也一样，你编的程序使用的片上外设另一CPU上没有，那这段程序就无法移植了。这就是话粗理不粗。书归正传，还是聊聊ARM＋uclinux开发模式下开发环境的建立（其实下面说到的东西不仅限于这种硬件平台和操作系统）

很久以前就在介绍嵌入式系统开发的书上见过“交叉编译环境”这词，当时觉得很玄，用了以后才知道，其实就是解决在谁的地盘上用谁的工具编谁的代码问题。

M开发论坛

编译的最主要的工作就在将你的程序转化成运行该程序的CPU所能识别的机器代码，不同的CPU有相应的编译器，另一方面。编译器本身也是程序，当然也要在某一个CPU平台上运行。于是交叉编译的交叉点就在那个编译器本身是CPU1上的一个程序，却在为CPU2编译代码（整个一个吃里扒外！）。这么一想，以前用51和dsp的开发软件（大部分都是IDE－集成开发环境）开发程序时，都算是交叉编译啦。当然，假如在你的ARM系统上，操作系统已经正常运行，并且你的资源足够多，你可以把PC机上运行的ARM编译工具移植到ARM上，然后所有该系统的应用程序都直接在ARM系统上编译，这就不算交叉编译，但假如有条件这么作，程序的开发或者移植就方便多了，因为整个开发过程又回到在自己PC机上编应用程序的那种模式了，那就是在自己的地盘上用自己的编译器编自己的应用程序。
与不使用操作系统的开发模式不同（此处的操作系统尤其指提供了专门的接口函数库的操作系统，目前的UCOS就不算），在目标板（就是实现系统的板子）使用操作系统的开发模式下，交叉编译环境中还需要该对应该操作系统的库。比如uclinux提供的uClibc。此时，开发用的主机上不光要有目标板CPU所需的编译工具，还要有对应操作系统的库，又因为一般库文件还要在开发机上拿目标CPU的编译器重新编译一下，所以还要把操作系统的原码也放到开发机上。（唉，跟目标板没什么关系，却要帮它背这么多东西，真是上辈子欠它的！！）。

字串5

虽然嵌入式系统的接口库至关重要，但大家似乎已经淡忘了它的存在。这些多是因为大家已经远离了刀耕火种的年代（需要告诉编译器需要的include路径，lib路径，以及lib的名称），集成的编译环境让我们编译链接的所有繁琐工作化作对BUILD按钮的潇洒一击。而且不论是windows环境，还是linux环境，都有环境变量去记录这些参数。。但尝试将/usr/lib目录改一个名字，你就会知道你不能无视他们的存在，因为操作系统的功能都是通过这些库来交给应用层程序使用的。当然假如你的系统不依靠任何操作系统，像最原始的那种完全自己实现所有代码，就只需要一个编译工具，少了这些罗嗦事。
以上的东西一般时候是没有必要仔细研究，但交叉环境下开发或移植比较大的程序时，你可能就需要了解编译器，链接器等开发工具的几乎所有重要参数。
我在开发时，主机完全使用的是linux，假如有条件，建议大家这样作，linux的使用没有想象的复杂（虽然我现在身边还要放一本关于linux使用的书籍），而且开发程序可以先在主机上调通，然后用交叉编译工具为目标系统重新编译一遍，可以这样做是因为主机是linux，目标系统跑uclinux，两个操作系统提供的应用程序接口几乎是一样的，所以程序几乎不用修改。