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

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

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

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

一、準備好交叉編譯環境

在安裝有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，是瑞昱提供的。）

二、準備好源代碼

準備好須要編譯的源代碼庫包，如capwap-0.93.3，須要注意的是，不只須要準備要編譯的源代碼庫包，還須要準備該源碼包依賴的包，例如capwap-0.93.3依賴安全加密相關的包openssl和多線程相關的包pthread，這些包也需經過編譯成靜態庫或動態庫供主承銷包調用。

三、修改Makefile

通常的源碼庫能夠經過運行./Configure來制定編譯器gcc，目標板的架構已經生產應用程序和庫的目錄。若是沒有Configure文件就須要手動打開Makefile文件來修改，主要須要修改的地方有：（1）編譯器的類型，（2）須要庫的頭文件路徑；（3）須要庫的連接路徑（4）生成應用程序的路徑。如openCapwap移植過程，將CC=gcc行用CC=mips-linux-gcc替換。

四、編譯源代碼

在源碼包的主路徑下運行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語言方面的錯誤，通常是和交叉編譯器版本不匹配引發的。

一步步解決完這些錯誤後，而後終於能夠生產對應目標板的應用程序了。可是生產相應的應用程序纔是萬里長征的第一步，讓程序正確的運行纔是最終目標。

五、安裝應用程序

安裝應用程序有兩種方法，一是將應用程序放到目標板的文件系統中，經過燒鏡像的方法將程序下載到目標板上；另外一種是經過像tftp的方法下載到目標板上。後一種方法便捷靈活，在調試程序的過程當中應用較多。須要注意的是，還須要將應用程序須要的動態庫也下載到目標板上，應用程序才能跑。例如在咱們移植capwap中出現，在完成燒錄後，運行WTP報錯。Error：系統化找不到pthread.so。分析：在終端中進入lib目錄，發現缺乏libpthread.so動態庫。故緣由在於RTL8198目標板SDK編譯時沒有將libpthread.so動態庫添加到目標板系統的lib庫文件當中。

六、運行調試應用程序

調試應用程序讓其可以正確的工做，纔是移植工做最重要的部分，這須要對應用程序的流程很熟悉，而後經過打印日誌的方法看程序運行的路徑，分析日誌與正確的流程的差別來肯定出錯的地方。常見的出錯地方有：（1）內存分配函數；（2）系統位數不同；（3）字節順序問題（大端小端）；（4）浮點數的表示問題等。如咱們在移植過程當中遇到的malloc函數行爲不一樣的問題。以上都是平時移植過程當中須要重點注意的地方。