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<char>::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 与其他的依赖库没有直接关系。

猜你喜欢

转载自blog.csdn.net/ljh081231/article/details/80532801