嵌入式linux應用程式移植方法總結

前段時間一直在做openCapwap的移植和除錯工作，現在工作已接近尾聲，編寫本文件對前段工作進行一個總結，分享下openCapwap移植過程中的經驗和感悟。江浩寫的《CAPWAP移植進展.docx》對openCapwap的移植過程有了比較詳細的描述，所以在此就不涉及技術細節了，本文件主要以openCapwap的移植為例，總結嵌入式linux應用程式移植的一般方法和步驟，為以後可能需要的移植工作提供一些的思路。

嵌入式linux應用程式移植的步驟包括：

1、準備好交叉編譯環境

在安裝有Linux作業系統的PC上安裝對於平臺的交叉編譯器，並將交叉編譯器加到環境變數中，如export PATH=$PATH:/opt /toolchain/rsdk-1.3.6-5281-EB-2.6.30-0.9.30/bin, 然後在終端介面裡看交叉編譯器版本，如敲mips-linux-gcc –v，顯示版本號則表示安裝成功。

（交叉編譯器一般是平臺廠商提供的，比如我們的交叉編譯器就是mips-linux-gcc，是瑞昱提供的。）

2、準備好原始碼

準備好需要編譯的原始碼庫包，如capwap-0.93.3，需要注意的是，不僅需要準備要編譯的原始碼庫包，還需要準備該原始碼包依賴的包，例如capwap-0.93.3依賴安全加密相關的包openssl和多執行緒相關的包pthread，這些包也需通過編譯成靜態庫或動態庫供主承銷包呼叫。

3、修改Makefile

一般的原始碼庫可以通過執行./Configure來制定編譯器gcc，目標板的架構已經生產應用程式和庫的目錄。如果沒有Configure檔案就需要手動開啟Makefile檔案來修改，主要需要修改的地方有：（1）編譯器的型別，（2）需要庫的標頭檔案路徑；（3）需要庫的連結路徑（4）生成應用程式的路徑。如openCapwap移植過程，將CC=gcc行用CC=mips-linux-gcc替換。

4、編譯原始碼

在原始碼包的主路徑下執行Make,除非運氣特別好，一般情況下是會報錯的，需要根據報錯的型別進行相應的修改。常見的報錯型別有：（1）依賴的庫包不支援該CPU架構，需要更換該架構的庫包，如Capwap自帶的openssl庫不支援mips。#error "This openssl-devel package does not work your architecture?"（2）依賴的庫沒有經過交叉編譯就拿來用了，如#error“./static/libssl.a: could not read symbols: File in wrong format”即libssl.a庫檔案格式是X86架構下的不支援mips架構。（3）原始碼中有c語言方面的錯誤，一般是和交叉編譯器版本不匹配引起的。

一步步解決完這些錯誤後，然後終於可以生產對應目標板的應用程式了。但是生產相應的應用程式才是萬里長征的第一步，讓程式正確的執行才是最終目標。

5、安裝應用程式

安裝應用程式有兩種方法，一是將應用程式放到目標板的檔案系統中，通過燒映象的方法將程式下載到目標板上；另一種是通過像tftp的方法下載到目標板上。後一種方法便捷靈活，在除錯程式的過程中應用較多。需要注意的是，還需要將應用程式需要的動態庫也下載到目標板上，應用程式才能跑。例如在我們移植capwap中出現，在完成燒錄後，執行WTP報錯。Error：系統化找不到pthread.so。分析：在終端中進入lib目錄，發現缺少libpthread.so動態庫。故原因在於RTL8198目標板SDK編譯時沒有將libpthread.so動態庫新增到目標板系統的lib庫檔案當中。

6、執行除錯應用程式

除錯應用程式讓其能夠正確的工作，才是移植工作最重要的部分，這需要對應用程式的流程很熟悉，然後通過列印日誌的方法看程式執行的路徑，分析日誌與正確的流程的差異來確定出錯的地方。常見的出錯地方有：（1）記憶體分配函式；（2）系統位數不一樣；（3）位元組順序問題（大端小端）；（4）浮點數的表示問題等。如我們在移植過程中遇到的malloc函式行為不同的問題。以上都是平時移植過程中需要重點注意的地方。