交叉編譯靜態庫

① 一文搞懂交叉編譯/跨平台開發

交叉編譯是將代碼在不同平台上進行編譯、運行程序的技術。常見的平台有基於linux/Unix架構的系統和Windows系統。大部分情況下，交叉編譯使用C/C++編寫，需具備相關語言背景，並了解CMake及其CMakeLists撰寫。

在進行交叉編譯時，關鍵在於指定編譯工具鏈。C和C++的編譯工具鏈分別用CMAKE_C_COMPILER和CMAKE_CXX_COMPILER表示。通常在自己的機器上使用CMake編譯代碼時，會使用特定的編譯工具鏈，如Ubuntu機器上用gcc。在不同平台上，需下載對應平台的編譯工具鏈。如在Ubuntu機器上編譯Arm-Linux版本，只需在cmake時指定對應的編譯工具鏈。

動態庫與靜態庫的區別在於，動態庫在運行時載入，靜態庫則直接打包進可執行文件。CMake默認編譯靜態庫，如需編譯動態庫，需在CMakeLists.txt中指定為「SHARED」。在使用動態庫時，需確保動態庫的位置已知。在Linux下，需指定動態庫位置，Windows下需將動態庫.DLL放置在可執行文件的同一目錄下。

Windows平台與其他幾個平台在編譯與動態庫使用上有顯著不同。Windows下編譯動態庫後會生成DLL和LIB文件。在CMakeList中需指定。在執行階段，將mylib.dll與demo.exe放在同一路徑下執行。Windows下的動態庫默認隱藏符號，因此需要暴露的符號需用__declspec(dllexport)標記，如函數、struct等。

SSH問題可能導致使用curl觸發網路請求時出現status code為0的情況，這通常由SSH引起。注意排除此類問題以避免混淆。

② CMake搭建編譯環境總結

目錄

前言
交叉編譯環境搭建是嵌入式開發者面對的常見挑戰，主要涉及在目標平台（如Arm板）上編譯代碼的過程。常見的編譯工具包括Makefile和CMake。本文將總結CMake在搭建編譯環境時的常用技巧。

入門案例：單個源文件

代碼路徑： 代碼路徑鏈接

工程結構

在開始使用CMake之前，需要構建工程結構，包括文件、目錄和CMakeLists.txt文件。

工程編譯

完成CMakeLists.txt文件編寫後，執行cmake命令（指定路徑），然後使用make命令編譯。

多個源文件

代碼路徑: 代碼路徑鏈接

工程結構

當工程包含多個文件和目錄時，使用一個CMakeLists.txt文件可能難以維護。因此，建議按照模塊結構，為每個主要模塊創建單獨的CMakeLists.txt文件，將文件和目錄按層次嵌套管理。

優點

頂層CMakeLists.txt負責設置工程屬性、交叉工具和包含子路徑的CMakeLists.txt文件。子路徑下的CMakeLists.txt主要關注編譯文件的路徑、目標生成路徑和編譯目標。

配置示例

配置頂層CMakeLists.txt時，應包含工程屬性、交叉工具設置和包含子路徑的CMakeLists文件。子路徑下的CMakeLists.txt應關注頭文件路徑、目標生成路徑和編譯目標。

其他用法

配置局部變數、設置全局變數、獲取全局變數、指定目標輸出路徑、設置環境變數等。

環境設置和編譯器配置

設置環境變數、編譯器路徑、依賴庫路徑、頭文件路徑、編譯器編譯選項、CMakeLists路徑嵌套等。

編譯警告和報錯設置

使用GCC設置編譯警告和報錯選項，例如打開所有警告並將其視為錯誤。

交叉編譯環境設置

配置默認庫、頭文件搜索路徑、交叉編譯工具鏈、浮點運算處理方式、動態庫編譯、靜態庫編譯和可執行文件編譯。

③ Android 編譯 FFmpeg 6.0 - 支持MediaCodec編解碼

在Android上編譯FFmpeg 6.0版本，已成功集成MediaCodec編解碼支持，包括H264和H265編碼。以下是編譯和集成的詳細步驟：

首先，使用Macos 13.2的GCC、Cmake和NDK 21的交叉編譯環境，構建了x264、mp3lame、fdk-aac和opencore-amr等第三方庫。FFmpeg 6.0版本默認支持MediaCodec硬體加速，無需額外開啟，加速選項包括在內。

配置編譯時，選擇靜態鏈接庫，禁用avdevice和postproc模塊，以減少生成的.a文件數量。為了方便，可以編寫腳本自動化configure和make命令。編譯過程中，遇到x264的pkg-config問題，需要指定其位置。

通過ld工具，將所有靜態庫合並成一個libffmpeg-org.so文件，便於使用。合並配置中需注意使用libgcc_real.a，而不是libgcc.a，以適應NDK 21環境。編譯完成後，將庫文件和頭文件添加到Android項目中，配置CmakeLists.txt並實現FFmpegCmd類以調用MediaCodec功能。

開源庫FFmpegCommand提供了基礎的音視頻處理功能，包括FFmpegUtils命令和自定義MediaCodec操作的示例。在實際測試中，使用MediaCodec編碼的效率更高，建議優先使用。

總的來說，FFmpeg 6.0的MediaCodec集成已經成功，可用於Android項目的音視頻編解碼。通過簡單的配置和集成，即可享受MediaCodec帶來的性能優勢。

④ 如何在windows上用ndk交叉編譯其他平台程序

目標 ：編譯arm64的.so庫

編譯方法：理論上應該有兩種交叉編譯方法，法一，在Linux伺服器上安裝交叉工具鏈，直接用交叉工具鏈進行編譯鏈接；法二，使用ndk完成交叉編譯，因為

ndk已經安裝好交叉編譯工具鏈，以及相關的系統庫和系統頭文件了。這兩種方法的區別在於，linux伺服器上的編譯使用的makefile和ndk使用的.mk
文件顯然不同。原因是ndk作為一個集成編譯環境，制定了一套特定的規則用於生成最終的編譯腳本。

這里簡單總結下，如何在windows用ndk進行交叉編譯arm64目標平台的.so庫：

step1:找到ndk開發工具包，官網之類的都可以下載，Android-ndk64-r10-windows-x86_64.rar文件

step2:解壓上述ndk工具包，將包含程序源文件和頭文件的文件夾testProject都放入android-ndk-r10下的samples目錄下。

放在其他地方當然也可以，但是後續相對路徑之類的不太好加，既然其他例子都放這，把代碼放這編譯是最保險的了。

step3:在testProject中增加一個jni的文件夾，必須要添加！！！！！！

step4:在jni文件夾中，添加一個Android.mk的文件，必須要添加！！！！！

step5:在jni文件夾中，添加一個Application.mk的文件與Android.mk並列，必須要添加！！！！！

step6:Android.mk和Application.mk合起來就類似於linux環境下的makefile編譯文件。

如何寫Android.mk，可以參考例子helllo-jni中jni文件夾下的Android.mk。

LOCAL_PATH:=$(call my-dir) #必須要寫的

include $(CLEAR_VARS) #必須要寫的

LOCAL_MODULE:=hello-jni #編譯出來的模塊名稱

LOCAL_SRC_FILES:=hello-jni.c #制定編譯的源文件名稱

include $(BUILD_SHARED_LIBRARY)#放在最後

除了上述變數之外，還有其他的指定的變數，

LOCAL_CFLAGS，用於指定編譯選項，這個和makefile中是完全一樣的，可以指定編譯選項-g，也可以指定編譯宏及宏值

LOCAL_LDLIBS，用於指定鏈接的依賴庫，這個可以makefile也是完全一樣的，可以指定鏈接庫用-l庫名，以及指定庫搜索路徑用_L路徑名

LOCAL_STATIC_LIBRARIES，指定鏈接的靜態庫名，makefile中沒有

LOCAL_C_INCLUDES，用於指定編譯頭文件的路徑，和makefile中不同，路徑前不需要加-I，直接寫路徑即可，可以是相對路徑或絕對路徑，

多個路徑之間用空格隔開。

編寫上述Android.mk碰到的問題有，

(1)使用默認的系統自動載入stl庫頭文件總是出錯，只好手動在LOCAL_STATIC_LIBRARIES指定sources/cxx-stl/stlport/stlport來完成對#include<string>這種c++形式的頭文件載入

(2)使用$(SYSROOT)/usr/include來完成對系統庫頭文件的載入，結果找不到sem_t符號，只好指定platforms/android-L/arch-arm64/usr/include

step7:Application.mk編寫

APP_STL指定使用的stl移植庫，動態或者靜態都行

APP_CPPFLAGS，指定app編譯的編譯選項

APP_ABI指定abi規范類型，例如arm64-v8a，也可以寫成ALL就是把所有的類型全部編一編

APP_PLATFORM指定編譯的platform名稱，這里可以寫成android-L或者不指定全編。

step8:編譯完成後，運行。

啟動cmd，使用cd /D進行到testProject的jni目錄下

step9:將android-ndk-r10下的ndk-build.cmd直接拖拽到cmd中，此時直接敲回車，就可以編譯了。當然也可以加一個 clean，清除編譯中間文件。

step10:檢查下編譯結果，編譯成功後在testProject中多了兩個文件夾與jni並列的，libs和obj。
編譯鏈接後的結果就在libs中！

⑤ Linux 交叉編譯FFmpeg庫

Linux 交叉編譯FFmpeg庫

配置環境

在Linux上配置NDK環境和FFmpeg，首先下載並解壓NDK，配置/etc/profile的環境變數，然後下載FFmpeg，解壓後使用./configure --help查看幫助文檔。

FFmpeg包含libavformat、libavcodec、libavutil、libswscale、libpostproc等模塊，為各種音視頻封裝格式的生成和解析、聲音/圖像編解碼、公共工具函數、視頻場景比例縮放和色彩映射轉換、後期效果處理以及工具和伺服器等。

編寫編譯腳本

定義NDK路徑，指定GCC路徑，設置FLAGS結合Linux環境修改，參考externalNativeBuild/xxx/build.ninja的傳參內容。學習資料推薦，免費報名學習音視頻知識，資料包括C/C++、Linux、FFmpeg等。

配置參數

優化大小、不編譯ffmpeg程序（命令行工具）、關閉avdevice模塊、關閉所有編碼器、關閉所有復用器、關閉所有濾鏡、開啟交叉編譯、設置GCC的前綴、關閉動態庫、開啟靜態庫、傳給gcc的參數等。

執行make完成編譯輸出

編寫腳本過程中注意關閉asm、許可權要求、手動創建輸出文件夾、命令行格式等。

移植到Android項目中使用

創建NDK項目，將編譯好的include文件夾復制到/src/main/cpp目錄下，將ffmpeg lib目錄下的文件復制到armeabi-v7a目錄下，Cmake文件中引入庫，即可愉快使用FFmpeg庫。

FFmpeg是純C的庫，需要在代碼中進行引用。顯示ffmpeg版本號完成整個流程。

至此，Linux交叉編譯FFmpeg庫的流程介紹完成。

⑥ 交叉編譯時提示 對'__C_ctype_b'的未定義引用

出現這種情況的原因，主要是C/C++編譯為obj文件的時候並不旅賣需要函數的具體實現，只要有函數的原型即可。但是在鏈接為可執行文件的時候就必須要具體的實現了。如果錯誤是未聲明的引用，那就是找不到函數的原型，解決辦法這里就不細致說了，通常是相關的頭文件未包含。
解決辦法
指定原因就好辦了，既然知道是缺少了函數的喊昌具體實現，那麼就給它這個函數的實現就好了。比如上面的例子，是因為缺失了dlopen、dlsym、dlerror、dlclose這些函數的實現，這幾個函數是用於載入動態鏈接庫的，編譯的時候需要添加-ldl來使用dl庫(這是靜態庫，在系統目錄下/usr/lib/i386-linux-gnu/libdl.a、/usr/lib/x86_64-linux-gnu/libdl.a)。
但是看上面編譯的時候是有添加-ldl選項的，那麼為什麼不行呢？
gcc 依賴順序問題
這個主要的原因是gcc編譯的時候，各個文件依賴順序的問題。
在gcc編譯的時候，如果文件a依賴於文件b，那麼編譯的時候必須把a放前面，b放後面。
例如:在main.c中使用了pthread庫相關函數，那麼編譯的時候必須是main.c在前，-lpthread在後。gcc main.c -lpthread -o a.out。
上面拆滲逗出現問題的原因就是引入庫的順序在前面了，將其放置在後面即可了。
g++ -o spider bloomfilter.o confparser.o crc32.o dso.o hashs.o md5.o qstring.o sha1.o socket.o spider.o threads.o url.o -rdynamic -lpthread -levent -lcrypt -ldl