動態庫交叉編譯

⑴ Android Studio cmake編譯FFmpeg以及Jni調用

NDK是一系列工具集，幫助開發者快速開發C（或C++）動態庫，並能自動打包為APK，減輕開發人員的打包工作。它集成交叉編譯器，提供mk文件隔離差異，只需修改mk文件，就能創建出.so文件，自動打包與Java應用。JNI是Java與C/C++溝通機制，用於調用本地代碼，實現高效性。Android Studio 2.2後引入cMake新開發方式，簡化NDK開發與調試。以下步驟完成Android下FFmpeg編譯與JNI調用。

首先，在Ubuntu中創建並配置FFmpegOnAndroid目錄，進行NDK安裝與配置。

1. 下載並解壓Android NDK，配置環境變數。

2. 編譯FFmpeg源代碼，修改configure文件以適應Android平台。

3. 編寫build.sh腳本編譯FFmpeg，執行腳本完成編譯。

編譯完成後，將FFmpeg庫文件移植至Android平台。

1. 使用最新Android Studio2.3.3，安裝cmake和ndk，新建包含C++支持的工程。

2. 在工程中創建native-lib.cpp文件，實現Java與C++間調用。

3. 配置CMakeLists.txt文件，指定庫文件路徑。

4. 修改jni部分代碼，集成FFmpeg功能。

5. 實現Java調用代碼，展示FFmpeg使用效果。

通過此過程，可以在Android設備上使用FFmpeg進行音視頻處理。詳細源碼可參考開源倉庫：[GitHub源碼下載地址](DaveBobo/JniFFmpeg)

相關參考文章包括：

1. [CSDN博客文章](blog.csdn.net/eastmoon5...)

2. [CSDN博客文章](blog.csdn.net/dagaozi/a...)

3. [CSDN博客文章](blog.csdn.net/hejjunlin...)

4. [CSDN博客文章](cnblogs.com/wanggang123...)

⑵ 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庫的流程介紹完成。

⑶ FFmpeg交叉編譯、腳本參數配置

一：下載並解壓ffmpeg源碼

使用git或wget下載ffmpeg源碼到/root/ff目錄，安裝git或wget後執行命令解壓。

檢查解壓後的文件。

使用tar命令解壓ffmpeg-3.4.tar.bz2文件。

使用unzip命令解壓NDK壓縮包。

查看目錄結構。

安裝make工具，用於自動化編譯工作，提高效率。

二：配置編譯腳本

定義環境變數，包括NDK目錄、架構下的so庫和頭文件、交叉編譯工具、CPU類型和輸出路徑。

使用env命令查看環境變數。

解決NDK版本r19後gcc兼容問題，通過修改cc路徑使用clang。

執行make命令進行編譯，使用-j參數指定並行任務數，編譯完成後執行make install安裝。

在指定路徑下生成輸出文件。

三：創建Shell腳本

創建並編輯android.sh文件，實現自動化交叉編譯流程。

調整腳本參數實現動態配置。

重新執行腳本，生成編譯結果。

⑷ 如何使用clang+llvm+binutils+newlib+gdb搭建交叉編譯環境

1，Build llvm/clang/lldb/lld 3.5.0等組件

1.0 准備：

至少需要從llvm.org下載llvm, cfe, lldb, compiler-rt,lld等3.5.0版本的代碼。

$tar xf llvm-3.5.0.src.tar.gz

$cd llvm-3.5.0.src

$mkdir -p tools/clang
$mkdir -p tools/clang/tools/extra
$mkdir -p tools/lld
$mkdir -p projects/compiler-rt

$tar xf cfe-3.5.0.src.tar.xz -C tools/clang --strip-components=1
$tar xf compiler-rt-3.5.0.src.tar.xz -C projects/compiler-rt --strip-components=1
$tar xf lldb-3.5.0.src.tar.xz -C tools/clang/tools/extra --strip-components=1
$tar xf lld-3.5.0.src.tar.xz -C tools/lld --strip-components=1
1.1 【可選】使用clang --stdlib=libc++時，自動添加-lc++abi。

libc++組件可以使用gcc libstdc++的supc++ ABI，也可以使用c++abi，cxxrt等，實際上自動添加-lc++abi是不必要的，這里這么處理，主要是為了方便起見。實際上完全可以在「clang++ -stdlib=libc++」時再手工添加-lc++abi給鏈接器。

這里涉及到鏈接時DSO隱式還是顯式的問題，早些時候ld在鏈接庫時會自動引入由庫引入的依賴動態庫，後來因為這個行為的不可控性，所以ld鏈接器的行為做了修改，需要顯式的寫明所有需要鏈接的動態庫，才會有手工添加-lc++abi這種情況出現。

--- llvm-3.0.src/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 18:49:06.663029075 +0800
+++ llvm-3.0.srcn/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 19:36:04.260071355 +0800
@@ -251,6 +251,7 @@
switch (Type) {
case ToolChain::CST_Libcxx:
CmdArgs.push_back("-lc++");
+ CmdArgs.push_back("-lc++abi");
break;

case ToolChain::CST_Libstdcxx:
1.2 【必要】給clang++添加-fnolibgcc開關。

這個開關主要用來控制是否連接到libgcc或者libunwind。

註：libgcc不等於libunwind。libgcc_eh以及supc++的一部分跟libunwind功能相當。

註：libgcc_s和compiler_rt的一部分相當。

這個補丁是必要的， 不會對clang的正常使用造成任何影響 ，只有在使用「-fnolibgcc"參數時才會起作用。

之所以進行了很多unwind的引入，主要是為了避免不必要的符號缺失麻煩，這里的處理相對來說是干凈的，通過as-needed規避了不必要的引入。

--- llvm-static-3.5.0.bak/tools/clang/lib/Driver/Tools.cpp 2014-09-10 13:46:02.581543888 +0800
+++ llvm-static-3.5.0/tools/clang/lib/Driver/Tools.cpp 2014-09-10 16:03:37.559019321 +0800
@@ -2060,9 +2060,15 @@
".a");

CmdArgs.push_back(Args.MakeArgString(LibClangRT));
- CmdArgs.push_back("-lgcc_s");
- if (TC.getDriver().CCCIsCXX())
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else {
+ CmdArgs.push_back("-lgcc_s");
+ if (TC.getDriver().CCCIsCXX())
+ CmdArgs.push_back("-lgcc_eh");
+ }
}

static void addProfileRT(
@@ -7150,24 +7156,50 @@
bool isAndroid = Triple.getEnvironment() == llvm::Triple::Android;
bool StaticLibgcc = Args.hasArg(options::OPT_static_libgcc) ||
Args.hasArg(options::OPT_static);
+
+
+
if (!D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");

if (StaticLibgcc || isAndroid) {
if (D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
} else {
if (!D.CCCIsCXX())
CmdArgs.push_back("--as-needed");
- CmdArgs.push_back("-lgcc_s");
+ if (Args.hasArg(options::OPT_fnolibgcc))
+ CmdArgs.push_back("-lunwind");
+ else
+ CmdArgs.push_back("-lgcc_s");
if (!D.CCCIsCXX())
CmdArgs.push_back("--no-as-needed");
}

if (StaticLibgcc && !isAndroid)
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc_eh");
else if (!Args.hasArg(options::OPT_shared) && D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");

// According to Android ABI, we have to link with libdl if we are
// linking with non-static libgcc.
--- llvm-static-3.5.0.bak/tools/clang/include/clang/Driver/Options.td 2014-08-07 12:51:51.000000000 +0800
+++ llvm-static-3.5.0/tools/clang/include/clang/Driver/Options.td 2014-09-10 13:36:34.598511176 +0800
@@ -788,6 +788,7 @@
def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group<f_Group>;
def fopenmp : Flag<["-"], "fopenmp">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fopenmp_EQ : Joined<["-"], "fopenmp=">, Group<f_Group>, Flags<[CC1Option]>;
+def fnolibgcc : Flag<["-"], "fnolibgcc">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, Group<f_Group>;
def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, Group<f_Group>;
def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;
1.3 llvm的其他補丁。

llvm/clang將gcc toolchain的路徑hard code在代碼中，請查閱tools/clang/lib/Driver/ToolChains.cpp。

找到x86_64-redhat-linux之類的字元串。

如果沒有你系統特有的gcc tripple string，請自行添加。

這個tripple string主要是給llvm/clang搜索gcc頭文件等使用的，不影響本文要構建的toolchain

1.4 構建clang/llvm/lldb

本文使用ninja。順便說一下，llvm支持configure和cmake兩種構建方式。可能是因為工程太大，這兩種構建方式的工程文件都有各種缺陷（主要表現在開關選項上，比如configure有，但是cmake卻沒有等）。llvm-3.4.1就是因為cmake工程文件的錯誤而導致了3.4.2版本的發布。

綜合而言，cmake+ninja的方式是目前最快的構建方式之一，可以將構建時間縮短一半以上。

mkdir build
cd build

cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_CXX_FLAGS="-std=c++11" \
-DBUILD_SHARED_LIBS=OFF \
-DLLVM_ENABLE_PIC=ON \
-DLLVM_TARGETS_TO_BUILD="all" \
-DCLANG_VENDOR="MyOS" ..

ninja

ninja install
如果系統原來就有clang/clang++的可用版本，可以添加：

-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
這樣就會使用系統的clang++來構建llvm/clang

2，測試clang/clang++。

自己找幾個簡單的c/cpp/objc等編譯測試一下即可。完整測試可以在構建時作ninja check-all

3，libunwind/libc++/libc++abi，一套不依賴libgcc, libstdc++的c++運行庫。

3.1 從https://github.com/pathscale/libunwind 獲取代碼。

libunwind有很多個實現，比如gnu的libunwind, path64的libunwind，還有libcxxabi自帶的Unwinder.

這里作下說明：

1)，gnu的libunwind會有符號缺失和沖突。

2)，libcxxabi自帶的Unwinder是給mac和ios用的，也就是只能在darwin體系構建。目前Linux的實現仍然不全，等linux實現完整了或許就不再需要path64的unwind實現了。

暫時建議使用pathscale的unwind實現。

mkdir -p build
cd build
cmake -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-m64" ..
ninja

mkdir -p /usr/lib
cp src/libunwind.so /usr/lib
cp src/libunwind.a /usr/lib
3.2 第一次構建libcxx.

必須先構建一次libcxx，以便後面構建libcxxabi。這里構建的libcxx實際上是使用gcc的libgcc/stdc++/supc++的。

打上這個補丁來禁止libgcc的引入：

diff -Nur libcxx/cmake/config-ix.cmake libcxxn/cmake/config-ix.cmake
--- libcxx/cmake/config-ix.cmake 2014-06-25 06:57:50.000000000 +0800
+++ libcxxn/cmake/config-ix.cmake 2014-06-25 09:05:24.980350544 +0800
@@ -28,5 +28,4 @@
check_library_exists(c printf "" LIBCXX_HAS_C_LIB)
check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
-check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
編譯安裝：

mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
..
ninja
ninja install
3.3，測試第一次構建的libcxx。

使用"clang++ -stdlib=libc++ -o test test.cpp -lstdc++"編譯簡單c++代碼，檢查是否出錯。(如果前面構建clang是已經apply了c++abi的鏈接補丁，這里會出現找不到c++abi的情況，跳過即可)

使用"ldd test"查看test二進制動態庫使用情況。可以發現，test依賴於libgcc_s/libc++/libstdc++。（多少有些不爽了吧？使用了libc++居然還要依賴libstdc++？）

⑸ 用arm-linux交叉編譯器使用動態庫時搜索標准路徑是什麼

/usr/lib , /橘源usr/libxx xx為數字，一般32或64，x32
標准頭好伍畢文友芹件搜索路徑:/usr/include/