1. 嵌入式系统开发为什么要采用交叉编译的方式
由于嵌入式系统资源匮乏，一般不能像PC一样安装本地编译器和调试器，不能在本地编写、编译和调试自身运行的程序，而需借助其它系统如PC来完成这些工作，这样的系统通常被称为宿主机。宿主机通常是linux系统，并安装交叉编译器、调试器等工具；宿主机也可以是Windows系统，安装嵌入式Linux集成开发环境。在宿主机上编写和编译代码，通过串口、网口或者硬件调试器将程序下载到目标系统里面运行。所谓的交叉编译，就是在宿主机平台上使用某种特定的交叉编译器，为某种与宿主机不同平台的目标系统编译程序，得到的程序在目标系统上运行而非在宿主机本地运行。这里的平台包含两层含义：一是核心处理器的架构，二是所运行的系统，这样，交叉编译有3种情形：（1）目标系统与宿主机处理器相同，运行不同的系统；（2）目标系统与宿主机处理器不同，运行相同的系统；（3）目标系统与宿主机处理器不同，运行不同的系统。实际上，在PC机上进行非Linux的嵌入式开发，哪怕使用IDE集成环境如Keil、ADS、Realview，都是交叉编译和调试的过程，只是IDE工具隐藏了细节，没有明确提出这个概念而已。
2. qt交叉编译调试环境的搭建有没有人搬过来
您最初的想法是正确的，x86平台的库放在电脑上即可。
而通过arm-linux-交叉编译工具链编译过的库，是需要放在
开发板的文件系统里面的，通用的做法一般是放在/lib或者/usr/lib
目录里面即可。或者也可放在其他目录中，但是需要配置一下LD_LIBRARY_PATH
环境变量。例如放在/home/qtlib目录中，由于这个不是系统默认的动态库目录，
需要设置环境变量LD_LIBRARY_PATH，在/etc/profile下面添加：
export LD_LIBRARY_PATH=/home/qtlib:$LD_LIBRARY_PATH
3. 如何交叉编译开源库
所谓的搭建交叉编译环境，即安装、配置交叉编译工具链。在该环境下编译出嵌入式Linux系统所需的操作系统、应用程序等，然后再上传到目标机上。
交叉编译工具链是为了编译、链接、处理和调试跨平台体系结构的程序代码。对于交叉开发的工具链来说，在文件名称上加了一个前缀，用来区别本地的工具链。例如，arm-linux-表示是对arm的交叉编译工具链；arm-linux-gcc表示是使用gcc的编译器。除了体系结构相关的编译选项以外，其使用方法与Linux主机上的gcc相同，所以Linux编程技术对于嵌入式同样适用。不过，并不是任何一个版本拿来都能用，各种软件包往往存在版本匹配问题。例如，编译内核时需要使用arm-linux-gcc-4.3.3版本的交叉编译工具链，而使用arm-linux-gcc-3.4.1的交叉编译工具链，则会导致编译失败。
那么gcc和arm-linux-gcc的区别是什么呢？区别就是gcc是linux下的C语言编译器，编译出来的程序在本地执行，而arm-linux-gcc用来在linux下跨平台的C语言编译器，编译出来的程序在目标机(如ARM平台)上执行，嵌入式开发应使用嵌入式交叉编译工具链。
工具/原料
电脑系统：win7系统。虚拟机系统：workstation6.5 。虚拟机安装的linux版本：fedora9.0。内核：linux2.6.25 。
方法/步骤
1
我使用的交叉编译工具链是arm-linux-gcc-4.4.3，把它放在linux系统的路径是图一
2
在linux系统的路径/home/song/share下放了交叉编译工具链arm-linux-gcc-4.4.3的压缩包，另一个版本的不用。有的人可能会问到怎么把这个压缩包弄到虚拟机的linux的系统的，我是通过samba服务从主机复制到虚拟机的，这里的share文件夹就是我samba服务器的工作目录，多了不说，这不是重点。
然后通过命令mkdir embedded 建立一个arm-linux-gcc的安装目录，如图二所示。当然安装路径和目录名称“embedded”可以依自己的喜好而定。
步骤阅读
然后通过命令将share文件夹下的arm-linux-gcc-4.4.3.tar.gz复制到这里的embedded文件夹下， 当然这里你也可以不进行这一步我这是为了方便以后管理，将arm-linux-gcc安装到embedded文件夹下，方便以后寻找。
然后使用tar命令：tar zxvf arm-gcc-4.4.3.tar.gz将embedded文件夹下的arm-linux-gcc-4.4.3.tar.gz解压缩安装到当前目录下
执行完解压缩命令，就已经将交叉编译工具链arm-linux-gcc-4.4.3安装到linux系统上了，这里默认安装到了图六所示的路径上。
接下来配置系统环境变量，把交叉编译工具链的路径添加到环境变量PATH中去，这样就可以在任何目录下使用这些工具。 vi /etc/profile 编辑profile文件，添加环境变量。
在profile中的位置处，添加图八所示的红线标注的一行，路径就是图六中的红线标注的路径后面加上/4.4.3/bin。
图八中的路径一定是你自己的安装路径，可以使用pwd命令查找一下那个bin目录的路径。添加完路径后，保存退出。接下来使用命令：source /etc/profile，是修改后的profile文件生效，如图九所示。
然后，使用命令：arm-linux-gcc -v查看当前交叉编译链工具的版本信息，如图九中的红线标注第③行所示。很明显 可以看到，如果不执行第②步，则查看版本信息不成功。
然后验证交叉编译工具链是否安装成功并且可以使用，如图九所示，随便找一个目录编辑一个hello源代码。
编辑好hello.c文件后，保存退出。然后使用交叉编译器对hello.c进行编译，并生成可执行文件hello
这里生成的hello文件并不能像gcc编译出来的文件那样直接使用“./hello”命令执行并显示内容 因为它是一个二进制文件，只能下载到开发板上执行！
至此，搭建交叉编译环境步骤结束。
4. arm-linux-gcc交叉编译器的制作，以及版本选择问题。
，需要必须有足够动经验来支持。
另外，用 RH9 的都是高手，我想你的知识不需要来提问了吧？
1、在 PC 上编译 arm 的程序当然需要较差编译器，这个需要自己安装，或者着现成的交叉编译器环境，一般是一个特殊参数编译出来的 gcc + binutils + glibc + linux-header。这个每个人动环境不同，一般都需要自己编译一个，当然没有特殊需求，也可以找现成的。不过很难找，因为这套环境还要和你动系统搭配，不然环境不匹配，连这个环境都不能运行，那就更谈不上编译东西了。
有关自己编译搭建交叉编译环境，可以看看一个特殊的 Linux 发行版 LFS 的分支： CLFS 。
2、移植分很多意思，移植有可能就意味着这套源代码不能在目标系统上面编译，需要你根据相应的知识去修改源代码来让这套代码适应目标编译器的要求，比如源代码有 SSE4 的优化，这套程序在非 SSE4 CPU 上无法编译运行，但目标机器连 SSE1 都不支持。那么就需要移植。
或者移植仅仅是根据新的环境进行编译，不需要进行源代码修改，只需要进行一下编译就能运行的程序，也可以称为移植，就是从一个环境、架构 -》另一个环境、架构。都可以称为移植，但真正的移植意味着修改程序源代码来适应新环境。你说的这种移植是最简单的移植。
3、决定目标硬件环境 -》搭建目标编译器 -》制作目标环境（内核，基础软件库）-》进行应用移植（移植需要的软件、主应用程序）-》搭建系统文件系统 -》导入目标系统-》启动目标系统&应用。说起来很简单，因为这是完全没有问题的条件下。
至于超级终端。那是用来控制目标系统的。目标系统有可能不能插键盘鼠标显示器，这就需要一个远程网络链接来进行控制。以及通过远程链接来发送数据。这都需要终端的支持。
虚拟机下面进行开发，不能发挥你的计算机的性能。而且因为隔着 VMware 的软件模拟层，可能还不会很方便的让你链接目标设备。
至于用 socket ，我还没见到你的目标需要这个东西，因为所有的东西都是现成的源代码。不需要你从 0 开始写，当然你想自己写一个系统内核，或者服务器程序，或者全套的系统+应用，我绝对不拦你，但希望你写完这套东西，能把源代码发布出来。
ads 可以认为是一个支持环境，他本身不是一个系统的开发 SDK 。
-------------------------------------
ads 没用过，印象里他还有模拟器，调试器什么的程序。功能上要比 Linux 开发环境，WinCE 环境下面的东西更多更偏向于硬件方面，毕竟 ads 是 arm 出品的，不太可能偏向于软件部分设计。Linux 和 WinCE 都是系统而不是硬件工具。
你可以认为交叉编译器是一个应用程序，一个输出器。把源代码输出为 arm 的代码，这个应用程序的输出，是靠他自己的环境，而不是当前系统的环境的。
当前系统的各个软件的版本，不能影响交叉编译器输出的环境（理论上，现实有的时候总是从别的地方给你打击……），交叉编译器一般至少有 gcc 、binutils 、glibc 库、linux kernel 头文件。
在软件需求上。
头文件谁都不依赖，glibc 只需要内核头文件，其他程序全都依赖于 glibc 。也就是所有程序都不依赖内核，仅仅是依赖于内核头文件。
gcc 和 binutils 是把程序源代码根据上面各个环节的需提供的功能来输出为上面环节里面的二进制程序。依赖你当前环境的，只有 gcc 和 binutils 两个程序的执行、控制环节。只有他们两个依赖的，而不是你的交叉编译后的程序。
至于编译器版本的选择，新版本功能更好，旧版本兼容更好。
这个要看你的实际需要了。应用程序源代码也调编译器的，同时也依赖于软件库的功能。
arm 开发建议稳定、兼容优先。当然也可以尝试最新的编译环境，来获取更好的优化（前提是还有什么代码优化的话）。
另外,团IDC网上有许多产品团购,便宜有口碑
5. 计算机网络设计实训报告
摘要：使用Linux进行嵌入式产品开发有一个很大的优势，就是开发资源丰富，且成本低廉；但是，技术路线复杂多样，专业人才相对匮乏是Linux嵌入式系统开发面临的一个难题。本文从实际应用的角度，探讨和研究Linux嵌入式系统开发中的平台选型问题，以期望对各位Linux开发研究者有些许裨益。
关键词：嵌入式系统 Linux开发平台 选型
1 嵌入式系统与Linux
按照电气工程师协会的一个定义：嵌入式系统是用来控制或监视机器、装置或工厂等的大规模系统的设备。具体说来，它是电脑软件和硬件的综合体；是以应用为中心，以计算机技术为基础，软硬件可裁减，从而能够适应实际应用中对功能、可靠性、成本、体积、功耗等严格要求的专用计算机系统。一般来说，嵌入式系统不能使用通用型计算机，而且运行的是固化的软件，终端用户很难或者不可能改变固件。而Linux也早已成为IT界家喻户晓的一个名字。概括说来，将Linux应用于嵌入式系统的开发有如下一些优点：
① Linux自身具备一整套工具链，容易自行建立嵌入式系统的开发环境和交叉运行环境，并且可以跨越在嵌入式系统开发中仿真工具(ICE)的障碍。
② 内核的完全开放，使得可以自己设计和开发出真正的硬实时系统；对于软实时系统，在Linux中也容易得到实现。
③ 强大的网络支持，使得可以利用Linux的网络协议栈将其开发成为嵌入式的TCP/IP网络协议栈。
2 嵌入式系统设计的过程
按照嵌入式系统的工程设计方法，嵌入式系统的设计可以分成三个阶段：分析、设计和实现。分析阶段是确定要解决的问题及需要完成的目标，也常常被称为“需求阶段”；设计阶段主要是解决如何在给定的约束条件下完成用户的要求；实现阶段主要是解决如何在所选择的硬件和软件的基础上进行整个软、硬件系统的协调实现。在分析阶段结束后，通常开发者面临的一个棘手的问题就是硬件平台和软件平台的选择，因为它的好坏直接影响着实现阶段的任务完成。
通常硬件和软件的选择包括：处理器、硬件部件、操作系统、编程语言、软件开发工具、硬件调试工具、软件组件等。
在上述选择中，通常，处理器是最重要的，同时操作系统和编程语言也是非常关键的。处理器的选择往往同时会限制操作系统的选择，操作系统的选择又会限制开发工具的选择。
3 硬件平台的选择
3.1 处理器的选择
嵌入式系统的核心部件是各种类型的嵌入式处理器。据不完全统计，目前全世界嵌入式处理器的品种总量已经超过1000多种，流行体系结构有30几个系列。但与全球PC市场不同的是，没有一种微处理器和微处理器公司可以主导嵌入式系统，仅以32位的CPU而言，就有100种以上嵌入式微处理器。由于嵌入式系统设计的差异性极大，因此选择是多样化的。
调查上市的CPU供应商，有些公司如Motorola、Intel、AMD很有名气，而有一些小的公司，如QED(Santa Clara.CA)虽然名气很小，但也生产很优秀的微处理器。另外，有一些公司，如ARM、MIPS等，只设计但并不生产CPU，他们把生产权授予世界各地的半导体制造商。ARM是近年来在嵌入式系统有影响力的微处理器制造商，ARM的设计非常适用于小的电源供电系统。Apple在Newton手持计算机中使用ARM，另外有几款数字无线电话也在使用ARM。
设计者在选择处理器时要考虑的主要因素有：
① 处理性能。一个处理器的性能取决于多个方面的因素，如时钟频率，内部寄存器的大小，指令是否对等处理所有的寄存器等。对于许多需用处理器的嵌入式系统设计来说，目标不是在于挑选速度最快的处理器，而是在于选取能够完成作业的处理器和I/O子系统。如果是面向高性能的应用设计，那么建议考虑某些新的处理器，其价格相对低廉，如IBM和Motorola Power PC。
② 技术指标。当前，许多嵌入式处理器都集成了外围设备的功能，减少了芯片的数量，降低了整个系统的开发费用。开发人员首先考虑的是，系统所要求的一些硬件能否无需过多的胶合逻辑(GL，Glue Logic)就可以连接到处理器上。其次是考虑该处理器的一些支持芯片，如DMA控制器，内存管理器，中断控制器，串行设备、时钟等的配套。
③ 功耗。嵌入式微处理器最大并且增长最快的市场是手持设备、电子记事本、PDA、手机、GPS导航器、智能家电等消费类电子产品。这些产品中选购的微处理器，典型的特点是要求高性能、低功耗。许多CPU生产厂家已经进入了这个领域。今天，用户可以买到一颗嵌入式的微处理器，其速度像笔记本中的Pentium一样快；而它仅使用普通电池供电即可，并且价格很便宜。如果用于工业控制，则对这方面的考虑较弱。
④ 软件支持工具。仅有一个处理器，没有较好的软件开发工具的支持也是不行的，因此选择合适的软件开发工具对系统的实现会起到很好的作用。
⑤ 是否内置调试工具。处理器如果内置调试工具可以大大缩小调试周期，降低调试的难度。
⑥ 供应商是否提供评估板。许多处理器供应商可以提供评估板来验证理论是否正确，决策是否得当。
3.2 硬件部件选择的其它因素
① 生产规模。打算做1套?多套?还是规模生产?如果生产规模比较大，可以自己设计和制备硬件，这样可以降低成本。反之，最好从第三方购买主板和I/O板卡。
② 开发的市场目标。如果想使产品尽快发售，以获得竞争力，此时要尽可能买成熟的硬件；反之，可以自己设计硬件，降低成本。
③ 软件对硬件的依赖性。软件是否可以在硬件没有到位的时候并行设计或先行开发。
④ 只要可能，尽量选择使用普通的硬件。在 CPU 及架构的选择上，一个原则是：只要有可替代的方案，尽量不要选择 Linux 尚不支持的硬件平台。
4 软件平台的选择
图1所示的嵌入式软件的开发流程，主要涉及到代码编程、交叉编译、交叉连接、下载到目标板和调试等几个步骤，因此软件平台的选择也涉及到以下几个方面。
4.1 操作系统的选择
(1)操作系统选择应考虑的因素
硬件方案确定之后，操作系统的选择就相对轻松了。硬件的不同，会影响操作系统的选择。低端无MMU(Memory Management Unit，存储器管理单元)的CPU，要使用uClinux 操作系统；而相对高端的硬件，则可以用普通的嵌入式 Linux 操作系统。uClinux 和普通的 Linux 有各自的优势和缺点。可用于嵌入式系统软件开发的操作系统很多，但关键是如何选择一个适合开发项目的操作系统。经过多年的开发实践，笔者认为应该从以下几点进行考虑：
① 操作系统提供的开发工具。有些实时操作系统(RTOS)只支持该系统供应商的开发工具，因此，还必须向操作系统供应商获取编译器、调试器等；而有些操作系统使用广泛，且有第三方工具可用，因此，选择的余地比较大。
② 操作系统向硬件接口移植的难度。操作系统到硬件的移植是一个重要的问题，是关系到整个系统能否按期完工的一个关键因素。因此,要选择那些可移植性程度高的操作系统，避免操作系统难以向硬件移植而带来的种种困难，加速系统的开发进度。
③ 操作系统的内存要求。均衡考虑是否需要额外花钱去购买RAM或EEPROM来迎合操作系统对内存的较大要求。
④ 开发人员是否熟悉此操作系统及其提供的API。
⑤ 操作系统是否提供硬件的驱动程序，如网卡等。
⑥ 操作系统的可剪裁性。有些操作系统具有较强的可剪裁性，如嵌入式Linux、Tornado/VxWorks等等。
⑦ 操作系统的实时性能。
(2)几类嵌入式Linux系统的比较
嵌入式Linux系统方面的产品主要分为三类：
第一类是专门为Linux的嵌入式应用而做的。如何让Linux更小、更容易嵌入到体积要求和功能、性能要求更高的硬件中去，是他们的产品开发方向，如MontaVista的MontaVista Linux等。第二类是专门为Linux的实时特性设计的产品。将Linux开
6. 如何构建交叉编译环境。
你说的是我下面的回答吗？下面就一些问题作一个说明，以期抛砖引玉。
基于Linux操作系统的应用开发环境一般是由目标系统硬件（开发板）和宿主PC机所构成。目标硬件开发板用于运行操作系统和系统应用软件，而目标板所用到的操作系统的内核编译、应用程序的开发和调试则需要通过宿主PC机来完成（所以称为交叉编译）。双方之间一般通过串口，并口或以太网接口建立连接关系。
但在此我建议构建如下的交叉编译环境，适合个人或研发小组使用：单独拿出一台PC机（PII以上即可，就用以前淘汰的旧机器就可以），在该PC上安装桌面的Linux操作系统（如Red Hat Linux 8.0及以上），可以采用默认的安装选项（注意要包含FTP服务），这台PC作为Linux服务器，除管理员以外，一般不直接让其他人去操作。
将该Linux服务器接入局域网，并新建一些合法用户，以便其他的PC机（在此我们将其称为工作站）的合法用户能访问到Linux服务器。而其他的PC机（工作站）仍然使用Windows操作系统,原来干啥继续干啥。
需要的软件工具包括：
1、FTP客户端程序（如Cuteftp，可到网上下载）。
2、Telnet工具（如SecureCRT，可到网上下载）。
3、移植到某一特定ARM平台的Linux操作系统内核源码（一般由销售商整理提供）。
4、GNU编译工具，可由相关网站下载，或由销售商整理提供。
在工作站安装：
在某工作站PC上安装FTP客户端程序和Telnet工具，安装完毕后应该可以在该工作站PC和Linux服务器之间进行文件的传输，并在工作站PC可以通过Telnet登陆到Linux服务器（可能需要将Linux服务器的防火墙服务关闭才能完成）。
在Linux服务器安装：
将工作站PC上的Linux操作系统内核源码压缩包和GNU编译工具通过FTP传送到Linux服务器的某个目录（如合法的用户目录），然后在该目录下解压，并将GNU编译工具安装到默认的工作目录即可，以上工作通过在工作站PC使用Telnet工具完成，而不需要在Linux服务器上进行。
Linux操作系统内核的编译：
Linux操作系统内核的编译一般有一个比较固定的步骤，会根据MakeFile文件的不同而略有差异，可参考相关文档，编译的工作在工作站PC使用Telnet工具完成。
7. 关于主机游戏移植到PC的问题如题 谢谢了
我理解的主机游戏开发的一般步骤是代码可以在PC上写，然后交叉编译为主机的目标代码，然后部署到主机Debug机上远程调试
如果使用跨主机和PC的引擎，当然可以先开发PC版作为原型，然后再为主机版优化，这时还是交叉编译＋远程调试
为什么PC版效果差？主机还是有些硬件比PC强的，XBOX360有3个3.2GHz的CPU，PS3是8核心3.2GHz的Cell(PPE + 7 * SPE)，用的是XDR RAM和GDDR3显存，某种程度上说比PC强啊。
8. 嵌入式系统的开发模式怎样什么是交叉编译和远程调试
记得其联系系统的开发模式样什么什么是膏片车祸远近调戏应该这个开发模式有什么交代的软件都要按到比例来的
9. 如何在 Intel x86 服务器上构建 IBM PowerLinux 应用程序 第2页
环境和配置
测试环境有一个 IBM Flex System® 组成，该系统有多个 IBM Flex System x240 计算节点和两个基于 IBM POWER7 处理器的节点（一个 Flex System p260 和一个 Flex System p460）。出于本项目的目的，我使用一个 Flex system x240 计算节点来交叉编译 Apache httpd 和 PostgreSQL。构建二进制程序后，我将它们转移到 Flex System p460 计算节点。图 7 显示了 IBM Flex System 测试环境的布局图。
图 7. IBM Flex System 测试环境
以下是我的系统配置、操作系统级别和其他与系统设置相关的信息。
Flex System x240 计算节点
用于交叉编译二进制程序的 Intel 节点仅需要足够的处理能力和内存，以便能够构建 Power 二进制程序。配置如下：
基于内核的虚拟机 (KVM) 管理程序 Red Hat 6.5
32 个处理器
64 GB 内存
IBM Storwize® V7000 存取区域网络 (SAN) 连接磁盘
KVM Guest 系统
Red Hat Enterprise Linux 6.5
4 个处理器
16 GB 内存
一个 virtio 磁盘：100 GB
一个配置为 br0 的虚拟网络接口卡 (NIC)
所有其他 KVM Guest 系统都已关闭，以消除破坏环境的任何可能性。
Flex System p440 计算节点
Flex System p440 计算节点包含多个逻辑分区 (LPAR)，其中一个配置为测试服务器。PowerLinux 服务器配置如下：
IBM PowerVM® 来宾
Red Hat Enterprise Linux 6.5
8 个处理器（专用）
32 GB 内存
Storwize V7000 SAN 连接磁盘 (50 GB)
通过虚拟 I/O 服务器 (VIOS) 共享的以太网适配器
LPAR 配置
最小内存：256 MB
目标内存：32 GB
最大内存：64 GB
最少处理器数：8
目标处理器数：8
最大处理器数：32
处理模式：专用
专用内存
虚拟以太网适配器（通过 VIOS 建立）
适配器 ID：2
VLAN ID：1
需要此适配器来激活虚拟服务器：已选择
以下是我运行的其他一些命令：
# ppc64_cpu --frequency
min: 3.56 GHz (cpu 28)
max: 3.56 GHz (cpu 4)
avg: 3.56 GHz
# ppc64_cpu --cores-present
Number of cores present = 8
# sysctl.conf
kernel.sem = 250 32000 32 12288
使用 toolchain 构建应用程序
通常，构建开源发行版的过程是一个迭代过程。如果您很幸运的话，该过程可能已构建完成。不幸的是，因为大多数开源发行版都构建于 x86 服务器之上，所以在尝试为不同架构（比如 IBM Power 架构）构建它们时可能遇到问题。
如果在 Power 上构建开源包时遇到问题，只需在互联网上搜索类似情形，查看这些已报告的问题是否与您的经历密切相关。如果是相关的，那么在大多数情况下，您可以找到如何解决该问题的建议。
对我而言，尽管为配置脚本选择正确参数后，postgresql 很好地构建完成了，但 apache httpd 没那么幸运。接下来的几节将介绍为 Power 架构构建 apache httpd 所需的修复程序。
交叉编译器经验
编写本文时，我使用的交叉编译器版本是一个仅供 IBM 内部使用的版本，它专为修复我在测试期间遇到的一个错误而构建。读者可以下载 AT 7.0-5 版，它是最新的交叉编译器（在发表本文时），拥有接下来的几段中描述的错误的修复程序。
在我尝试交叉编译 apr-1.5.1 源代码发行版时，我看到了以下编译器消息。
"sorry - this program has been built without plugin support"
按照我在互联网上搜索可能的帮助和解决方案的建议，我找到多个链接提到编译器需要使用 “plugin enabled” 选项来构建。我向 toolchain 支持小组报告了此问题，toolchain 维护人员很快就回复了我，为我提供了一个使用 plugin enabled 选项构建的修改版本。请注意，toolchain 的交叉编译器和原生编译器版本都需要使用 plugin enabled 选项构建。我能够在获得拥有该修复程序的 toolchain 版本后继续工作。
这是我使用 PowerLinux toolchain 的第一次经历。
交叉编译 httpd 2.4.3
要交叉编译 Apache httpd，需要使用另外 3 个包。它们是：apr、apr-util 和 pcre。找到下载最新包的位置后，开始使用 toolchain 交叉编译器在 x86 服务器上构建它们。
我构建 apr-1.5.1 时遇到的问题是构建 gen_test_char.o 模块。请参阅 ASF Bugzilla – 错误 51257 了解有关的更多细节。我修改了 Makefile.in 文件（如下所示）并运行 buildconf 脚本，以便将更改包含在配置脚本中。
对 Makefile.in 的修改如下所示：
[root@stgisv240 apr-1.5.1]# diff -u Makefile.in ../../apr-1.5.1/Makefile.in
--- Makefile.in 2014-03-17 10:10:26.000000000 -0500
+++ ../../apr-1.5.1/Makefile.in 2014-07-03 13:36:11.125013781 -0500
@@ -46,7 +46,6 @@
CLEAN_TARGETS = apr-config.out apr.exp exports.c export_vars.c .make.dirs build/apr_rules.out tools/gen_test_char@EXEEXT@ - tools/gen_test_char.o tools/gen_test_char.lo \
include/private/apr_escape_test_char.h
DISTCLEAN_TARGETS = config.cache config.log config.status include/apr.h include/arch/unix/apr_private.h @@ -132,10 +131,9 @@
make_tools_dir:
$(APR_MKDIR) tools
-OBJECTS_gen_test_char = tools/gen_test_char.lo $(LOCAL_LIBS)
-tools/gen_test_char.lo: make_tools_dir
-tools/gen_test_char@EXEEXT@:$(OBJECTS_gen_test_char)
- $(LINK_PROG) $(OBJECTS_gen_test_char) $(ALL_LIBS)
+tools/gen_test_char@EXEEXT@: make_tools_dir
+tools/gen_test_char@EXEEXT@: tools/gen_test_char.c
+ $(BUILD_CC) $(CFLAGS_FOR_BUILD) $< -o $@
include/private/apr_escape_test_char.h: tools/gen_test_char@EXEEXT@
$(APR_MKDIR) include/private
修改 Makefile.in 文件后，我运行 buildconf 来创建了一个新配置脚本。下一段将介绍用于配置脚本的参数和变量。顺便说一下，我是根据其他尝试在其他平台（比如 ARM）上交叉编译 Apache httpd 及其组件的开发人员的建议，为配置脚本选择配置参数的。
以下是我在 x86 服务器上运行 apr-1.5.1 组件的配置脚本时，使用的参数和环境变量。
# Config script using Power Linux toolchain on x86
BUILD_CC=gcc
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=powerpc64-linux-cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local/apr --host=powerpc64-linux ac_cv_file__dev_zero=no
ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1
BUILD_CC=gcc make install
我在 Power 服务器上了略加修改的相同发行版。请注意，用于 Power 服务器的 PowerLinux toolchain 使用了具有类似命名的可执行程序，比如从原生 cpp 和 binutils 包安装的 cpp 和 ld。修改脚本中的 CPP 和 LD 变量，如下所示。确保 Power toolchain 的路径首先传入您的 PATH 环境中。
以下是我在 Power 服务器上运行 apr-1.5.1 的配置脚本时使用的参数和环境变量。
# Config script using PowerLinux toolchain on Power
BUILD_CC=gcc
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=cpp # Note the difference
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=ld # Note the difference
STRIP=powerpc64-linux-strip
#CFLAGS="-mcpu=440fp -mtune=440fp --sysroot $SYSROOT"
#LDFLAGS=-L$SYSROOT/lib
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local/apr ac_cv_file__dev_zero=no
ac_cv_func_setpgrp_void=no apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1
ac_cv_struct_rlimit=yes
BUILD_CC=gcc make install
以下是我在 x86 服务器上运行 apr-util-1.5.3 组件的配置脚本时使用的参数和环境变量。
# Configure script for apr-util-1.5.3 on x86
BUILD_CC=gcc
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=powerpc64-linux-cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local/apr --host=powerpc64-linux --with-
apr=/tmp/usr/local/apr ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no
apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1
以下是我在 Power 服务器上运行 apr-util-1.5.3 组件的配置脚本时使用的参数和环境变量。
# Configure script for apr-util-1.5.3 on Power
BUILD_CC=gcc
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=ld
STRIP=powerpc64-linux-strip
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local/apr --host=powerpc64-linux --with-
apr=/tmp/usr/local/apr ac_cv_file__dev_zero=no ac_cv_func_setpgrp_void=no
apr_cv_tcp_nodelay_with_cork=no ac_cv_sizeof_struct_iovec=1
以下是我在 x86 服务器上运行 httpd 组件的配置脚本时使用的参数和环境变量。
# Configure script for httpd 2.4.3 on x86
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=powerpc64-linux-cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local --host=ppc64 ap_cv_void_ptr_lt_long=no --with-
pcre=/tmp/usr/local/bin/pcre-config --with-apr=/tmp/usr/local/apr --with-mpm=worker--
with-apr-util=/tmp/usr/local/apr/bin/apu-1-config
以下是我在 Power 服务器上运行 httpd 组件的配置脚本时使用的参数和环境变量。
# Configure script for httpd 2.4.3 on Power
CC_FOR_BUILD=gcc
CC=powerpc64-linux-gcc
CPP=cpp
AS=powerpc64-linux-as
#ASCPP=powerpc-apm-linux-gnu-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
#CXXCPP=powerpc-apm-linux-gnu-cpp
CXX=powerpc64-linux-c++
LD=/opt/at7.0-5-rc1/bin/ld
STRIP=powerpc64-linux-strip
#CFLAGS="-mcpu=440fp -mtune=440fp --sysroot $SYSROOT"
#LDFLAGS=-L$SYSROOT/lib
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local --host=ppc64 ap_cv_void_ptr_lt_long=no--with-
pcre=/home/usr/local/bin/pcre-config --with-apr=/home/usr/local/apr --with-mpm=worker--
with-apr-util=/home/usr/local/apr/bin/apu-1-config
交叉编译 PostgreSQL 9.4.3
不同于之前构建 httpd 所需的源代码发行版，我在交叉编译 PostgreSQL 时未遇到问题。PostgreSQL 是使用以下配置脚本来构建的。
以下是我在 x86 服务器上运行 PostgresSQL 的配置脚本时使用的参数和环境变量。
# Configure script for postgresql-9.3.4 on x86
CC=powerpc64-linux-gcc
CPP=powerpc64-linux-cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
D=powerpc64-linux-ld
STRIP=powerpc64-linux-strip
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/tmp/usr/local --host=powerpc64-linux --without-readline --without-zlib
与 Apache 配置脚本一样，您可以注意到针对 Power 服务器 toolchain 使用了具有类似命名的可执行程序，比如从原生 cpp和 binutils 包安装的 cpp 和 ld。修改脚本中的 CPP 和 LD 变量，如下所示。确保 toolchain 的路径首先传入您的 PATH 环境中。
以下是我在 Power 服务器上运行 PostgresSQL 的配置脚本时使用的参数和环境变量。
# Configure script for postgresql-9.3.4 on Power
CC=powerpc64-linux-gcc
CPP=cpp
AS=powerpc64-linux-as
AR=powerpc64-linux-ar
RANLIB=powerpc64-linux-gcc-ranlib
CXX=powerpc64-linux-c++
LD=powerpc64-linux-ld
STRIP=powerpc64-linux-strip
export CC CPP AS ASCPP AR RANLIB CXXCPP CXX LD STRIP CFLAGS LDFLAGS CC_FOR_BUILD
./configure --prefix=/home/usr/local --host=powerpc64-linux --without-readline --without-zlib
结束语
toolchain 交叉编译器的实际价值在于，开发人员可在他们熟悉的开发平台上（在大多数情况下是 x86）编译和构建 Power Architecture 应用程序。从我们的用例中可以看到，toolchain 可生成像原生编译的应用程序一样高效地执行的二进制可执行程序和库。而且，交叉编译的库与原生编译的应用程序兼容。最后但同样重要的是，交叉编译的应用程序可在本地调试以及使用 gdb 调试器远程调试。
PowerLinux toolchain 与在 x86 平台上使用原生 Linux toolchain 没什么不同。希望本文能让读者很好地了解 PowerLinux toolchain 的特性和功能。