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

wuruixn發表於2020-04-07

前段時間一直在做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函式行為不同的問題。以上都是平時移植過程中需要重點注意的地方。

相關文章