webrtc封装sdk（五）编译webrtc android遇到的问题

按照官方的编译步骤就可以编译出android版本的各个静态库libxxx.a
当我们使用这些静态库，并且还需要编译自己写的那些c++代码时，可能会遇到以下两个问题

• 自己本地的android ndk和webrtc内部使用的ndk版本不同

• ndk版本相同但是stl的libc++库类型不同，如llvm-libc++,gnustl,stlport等

以上两个问题会导致如下类型的链接错误：

undefined reference to 'std::__ndk1::locale::~locale()'
undefined reference to 'std::__ndk1::ctype::id'
undefined reference to 'std::__ndk1::ios_base::clear(unsigned int)'
undefined reference to 'std::__ndk1::ios_base::getloc() const'

如果需要查找到底哪个libstdc++.a含有这写符号，可以ndk目录下批量nm|grep一下看看。

下面讲解一下如何解决上面两个问题。

1、和webrtc使用相同版本的ndk

仔细阅读webrtc源码中的文件build/config/android/config.gni，可以发现webrtc默认使用的ndk版本和sdk版本为r12b：

    if (!defined(default_android_ndk_root)) {
    default_android_ndk_root = "//third_party/android_tools/ndk"
    default_android_ndk_version = "r12b"
    default_android_ndk_major_version = 12
  } else {
    assert(defined(default_android_ndk_version))
    assert(defined(default_android_ndk_major_version))
  }

并且可以发现webrtc使用的是llvm-libc++类型的c++库为：

android_libcpp_root = "$android_ndk_root/sources/cxx-stl/llvm-libc++"

我们根据这个版本去下载一个同样版本的ndk: https://dl.google.com/android/repository/android-ndk-r12-darwin-x86_64.zip
安装到系统或者直接使用webrtc中的ndk。

进入ndk目录，并且执行以下命令创建standalone toolchain，重点关注参数--stl=libc++

参数也可以取其它值，可以阅读以下make-standalone-toolchain.sh脚本的内容。

./build/tools/make-standalone-toolchain.sh --platform=android-16 \
--install-dir=./my-android-toolchain --stl=libc++

把生成的my-android-toolchain拷贝到~/my-android-toolchain，
这样就生成了和webrtc相同版本的ndk

2、使用llvm-libc++类型的toolchain编译自己的代码

我们使用cmake>=3.7.2版本和上一步生成的~/my-android-toolchain
就可以很简单的编译我们自己项目的android版本

cmake_minimum_required(VERSION 3.7)
project(webrtc_test)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fpic")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fpic -std=c++11")
include_directories(${PROJECT_SOURCE_DIR} "./include/")
FILE(GLOB SOURCE
"./*.cc")
add_library(webrtc_test ${SOURCE})

使用如下命令来运行cmake:

cmake -DCMAKE_SYSTEM_NAME=Android \
-DCMAKE_ANDROID_STANDALONE_TOOLCHAIN=~/my-android-toolchain \
-DCMAKE_BUILD_TYPE=Debug .. 
cmake --build .

这样就完成了android sdk的编译，怎么样很简单吧？

注意这里一定要是用cmake 3.7.2的版本，因为低版本不支持DCMAKE_ANDROID_STANDALONE_TOOLCHAIN参数
目前测试cmake 3.8无法编译通过，所以推荐使用cmake 3.7.2

有的朋友以前可能会使用一个开源项目叫做android-cmake来编译android
里面有一个toolchain配置文件android.toolchain.cmake
但是目前这个文件只支持ndk版本小于等于r10d的版本
在高版本ndk中由于ndk目录结构发生改变，无法再使用android.toolchain.cmake文件了
所以建议大家以后放弃使用android.toolchain.cmake文件，而直接使用系统安装的cmake+standalone-toolchain即可。

3、android链接小技巧

android在链接时会依赖库的链接顺序，如果你觉得这样很难搞清楚先后顺序，可以试一下把所有静态库.a合并为一个大的整体库liball.a，在同一个库中的.o文件是没有顺序问题的。

（本文基于webrtc branch55编写,在macos 10.12上测试）

关键词：webrtc android 编译 webrtc链接

欢迎打赏，QQ、微信：596639669，github:zhangpengyf

作者：我是榜样
链接：https://www.jianshu.com/p/f25e36da63dc
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

android ndk编译C++ 的undefined reference to '__cxa_end_cleanup'及 __gxx_personality_v0问题

出现这两个错误主要是由于缺少stl支持导致的。

android 的ndk默认是不带 stl相关属性的

这就导致他编译C++代码的时候有时候会链接失败，报一些函数找不到。

比如这两个：

__cxa_end_cleanup 

和   __gxx_personality_v0   

这些stl相关的库不在$(NDK_ROOT)/platforms/android-9/arch-arm/usr/lib里面，而在$(NDK_ROOT)/sources/cxx-stl 下面你用grep 可以看到 

hl@hl-VirtualBox:/opt/android-ndk-r8c/sources/cxx-stl$ grep -rnH "__cxa_end_cleanup"  ./  

Binary file ./gnu-libstdc++/4.4.3/libs/armeabi-v7a/libsupc++.a matches

Binary file ./gnu-libstdc++/4.4.3/libs/armeabi-v7a/libgnustl_shared.so matches

Binary file ./gnu-libstdc++/4.4.3/libs/armeabi-v7a/libgnustl_static.a matches

Binary file ./gnu-libstdc++/4.4.3/libs/armeabi/libsupc++.a matches

Binary file ./gnu-libstdc++/4.4.3/libs/armeabi/libgnustl_shared.so matches

Binary file ./gnu-libstdc++/4.4.3/libs/armeabi/libgnustl_static.a matches

Binary file ./gnu-libstdc++/4.6/libs/armeabi-v7a/libsupc++.a matches

Binary file ./gnu-libstdc++/4.6/libs/armeabi-v7a/libgnustl_shared.so matches

Binary file ./gnu-libstdc++/4.6/libs/armeabi-v7a/libgnustl_static.a matches

Binary file ./gnu-libstdc++/4.6/libs/armeabi/libsupc++.a matches

Binary file ./gnu-libstdc++/4.6/libs/armeabi/libgnustl_shared.so matches

Binary file ./gnu-libstdc++/4.6/libs/armeabi/libgnustl_static.a matches

如果你用ndk自带的nm命令查看这个 libsupc++.a就会发现它里面是有__cxa_end_cleanup 这个函数定义的

hl@hl-VirtualBox:/opt/android-ndk-r8c/sources/cxx-stl$ arm-linux-androideabi-nm ./gnu-libstdc++/4.6/libs/armeabi-v7a/libsupc++.a | grep __cxa_end_cleanup 

         U __cxa_end_cleanup

00000000 T __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

         U __cxa_end_cleanup

所以我们在编译C++代码的时候如果遇到这类问题，就在Android.mk里面加上：

STL_PATH=$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi-v7a

以及

LOCAL_LDLIBS += -L$(STL_PATH) -lsupc++

即可解决这个问题

再次感谢此文作者，说的很详细，对我启发很大

http://blog.csdn.net/andyhuabing/article/details/8591459  

选择 runtime 版本

安卓系统默认只提供了一个非常简单的 C++ 运行时环境：system。它不包含 STL、异常、RTTI 等特性，那我们的代码里面就不能使用这些特性，例如不能使用 std::string 或者 std::vector，不能使用 try-catch，不能使用 typeid 操作符。不过好在 NDK 提供了其他辅助的运行时环境，它们能提供不同的 STL 实现，异常和 RTTI 支持。

• system：最基本的 C++ 运行时；
• gabi++_static/gabi++_shared：GAbi++ 运行时，包括异常、RTTI 支持；
• stlport_static/stlport_shared：STLport 运行时，包括异常、RTTI、STLport 的 STL 实现；
• gnustl_static/gnustl_shared：GNU STL 运行时，包括异常、RTTI、GNU STL 的实现；
• c++_static/c++_shared：LLVM libc++ 运行时，包括异常、RTTI、LLVM libc++ 的 STL 实现；

如何选择运行时环境，主要考虑两个问题：哪个 STL 实现？静态还是动态？

选择哪个 STL 实现，可以参考以下方面：

• 是否活跃维护：STLport 已经好几年没有更新了，source forge 上面最新版本还是 14 年 7 月的版本；
• License：GNU STL 使用 GPLv3 许可，这可是“病毒许可”，小公司也许可以无所谓，人家根本不会注意到你，但大公司就要小心了；
• libc++ 虽然有将它们都取而代之的雄心壮志，但仍不够稳定；
• 最后但也同样重要的：编译依赖库时能统一为哪一 STL；

由于我们这里并不追求极致的稳定性，当然更主要还是因为 WebRTC 是用 libc++ 编译的，所以我选用了 libc++ 这一运行时环境。前面就已经提到，我们必须使用 libc++ runtime，否则会报一大堆 undefined reference 错误，这是因为各个运行时库的二进制接口并不兼容，编译的时候混用 STL 实现，很容易遇到 undefined reference 错误。

链接静态依赖库（英文里叫做 link against）时，会把库中的目标文件打包到自己的库里面来，这样就可以不带着依赖库了，但如果我们有多个库都依赖了同一个库，那链接静态依赖库就会导致同样的目标文件被包含了多份，这样既占用了磁盘空间，也会占用运行时内存，而且 C++ 运行时库如果同时存在多份，可能会导致各种诡异的问题。此外，我们使用的依赖库可能别的程序也使用了（尤其是 C++ 运行时库），而如果操作系统中运行的多个程序如果要加载同一个动态库，那实际上只会加载一份，所以链接动态依赖库还有可能减少整个系统的内存占用。

最后，依赖库可以动态与静态混用，只要编译使用的 STL 一致即可，而 C++ 运行时库其实也是我们的依赖库，因此我们使用静态还是动态版本，与其他依赖库没有直接关系，即使用 c++_shared 或者 c++_static 与其他的依赖库没有直接关系。