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 的特性和功能。