📚 课程目录第3章 WebRTC Native源码编译与调试

3. WebRTC Native源码编译与调试：在Ubuntu/ARM环境下编译WebRTC M114版本

说实话，WebRTC的Native编译，是很多嵌入式开发者的第一道坎。我见过太多人卡在depot_tools的下载上，或者被GN参数折腾到怀疑人生。我自己第一次编译M76版本时，也花了整整两天才跑通——嗯，那时候还不懂ARM交叉编译的坑。

这一章，我们就来啃这块硬骨头。目标很明确：在Ubuntu x86主机上，为ARM平台交叉编译WebRTC M114，然后用GDB远程调试，配合日志分析，把整个链路打通。

3.1 环境准备与depot_tools配置

先说说我的个人习惯。我一般会在/opt下建一个webrtc_build目录，专门放编译工具链和源码。这样不会污染系统环境，也方便多版本切换。

核心依赖清单

Ubuntu 20.04/22.04 LTS（我推荐22.04，GCC版本更友好）
Python 3.8+（depot_tools依赖）
Git 2.25+
ARM交叉编译工具链：gcc-arm-linux-gnueabihf
Ninja构建系统（depot_tools自带）

安装depot_tools其实很简单，但有个细节要注意——不要用root用户。我曾经在服务器上直接用root拉代码，结果权限问题搞得一塌糊涂。

# 克隆depot_tools
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=$PWD/depot_tools:$PATH

# 配置环境变量（建议写入~/.bashrc）
echo "export PATH=$PWD/depot_tools:\$PATH" >> ~/.bashrc
echo "export DEPOT_TOOLS_UPDATE=0" >> ~/.bashrc  # 禁止自动更新，避免版本漂移

小技巧：设置DEPOT_TOOLS_UPDATE=0可以防止depot_tools每次运行都检查更新。在嵌入式开发中，版本一致性比新特性更重要。

3.2 拉取WebRTC M114源码

WebRTC的源码仓库非常大，M114版本大概有8GB左右。我第一次拉取时没加--no-history，结果等了三个小时……后来学乖了。

# 创建工作目录
mkdir webrtc_m114 && cd webrtc_m114

# 获取源码（只拉取最新版本，不要历史记录）
fetch --nohooks webrtc

# 切换到M114分支
cd src
git checkout branch-heads/5735  # M114对应的分支号

# 同步依赖
gclient sync -D

这里有个坑：gclient sync可能会因为网络问题失败。我建议用代理，或者配置国内镜像源。如果你在公司内网，记得提前配好HTTP代理。

避坑指南：我曾经在同步时遇到fatal: unable to access错误，折腾了半天才发现是SSL证书问题。解决方案是设置git config --global http.sslVerify false，但仅限内网环境。

3.3 GN参数配置：ARM交叉编译

GN是WebRTC的元构建系统，说白了就是生成Ninja构建文件的工具。配置GN参数是整个编译过程中最需要耐心的环节。

我个人习惯把GN参数写到一个独立的文件中，方便复用。下面是我为ARM平台准备的配置：

# arm_release.gn
import("//build/config/arm.gni")

target_os = "linux"
target_cpu = "arm"
target_sysroot = "/opt/arm-sysroot"  # 你的ARM根文件系统路径

# 启用RTC相关功能
rtc_use_h264 = true
rtc_include_ilbc = false
rtc_include_opus = true
rtc_build_examples = false
rtc_build_tests = false

# 优化选项
is_debug = false
symbol_level = 1  # 保留符号表，方便调试
optimize_for_size = true

# ARM特定配置
arm_version = 7
arm_float_abi = "hard"
arm_use_neon = true

然后执行GN生成构建文件：

gn gen out/arm_release --args="$(cat arm_release.gn | tr '\n' ' ')"

关键参数说明

参数	取值	说明
`target_cpu`	`"arm"`	目标CPU架构，ARM 32位
`target_sysroot`	路径	ARM根文件系统，包含交叉编译的库和头文件
`symbol_level`	1	保留函数名和行号，不保留局部变量
`arm_float_abi`	`"hard"`	硬浮点ABI，性能更好

3.4 编译与常见错误处理

配置好GN后，编译就简单了：

ninja -C out/arm_release webrtc

但简单不代表顺利。我总结了几种最常见的编译错误：

找不到sysroot：检查target_sysroot路径是否正确，确保里面有usr/lib/arm-linux-gnueabihf等目录。
NEON指令集错误：如果目标CPU不支持NEON，把arm_use_neon = false。
链接错误：undefined reference：通常是缺少某个库，检查sysroot是否完整。

我的经验：如果编译中途失败，不要直接重新运行ninja。先执行ninja -C out/arm_release -t clean清理，再重新编译。否则残留的.o文件可能引发奇怪的问题。

3.5 GDB远程调试：从主机到ARM设备

编译通过只是第一步。真正的挑战在于调试。在ARM设备上跑WebRTC，出问题了怎么查？我的方案是：主机上用GDB远程调试ARM目标。

先说说原理。我们需要两个东西：

ARM目标设备上运行gdbserver
主机上运行arm-linux-gnueabihf-gdb

具体步骤：

# 1. 在ARM设备上启动gdbserver
gdbserver :1234 ./webrtc_example

# 2. 在主机上连接
arm-linux-gnueabihf-gdb out/arm_release/webrtc_example
(gdb) target remote 192.168.1.100:1234
(gdb) continue

这里有个关键点：符号表路径必须正确。GDB需要知道在哪里找源码和调试符号。我一般会在GDB中设置：

(gdb) set sysroot /opt/arm-sysroot
(gdb) set substitute-path /build/webrtc/src /home/user/webrtc_m114/src

避坑指南：我曾经在调试时发现断点打不上，折腾了半天才发现是编译时symbol_level=0，没有生成调试符号。记住，调试版本一定要设置symbol_level=1或2。

3.6 日志分析：RTC_LOG的妙用

GDB断点调试虽然强大，但有些问题需要看运行时日志。WebRTC内置了RTC_LOG宏，可以输出不同级别的日志。

启用日志很简单：

# 在ARM设备上运行程序时设置环境变量
RTC_LOG_THRESHOLD=INFO ./webrtc_example
RTC_LOG_FILE=/tmp/webrtc.log ./webrtc_example  # 输出到文件

日志级别从低到高：VERBOSE > INFO > WARNING > ERROR。我一般调试时用INFO级别，生产环境用WARNING。

举个例子，如果你想看ICE连接过程：

// 在代码中
RTC_LOG(INFO) << "ICE connection state: " << state;
RTC_LOG(LS_VERBOSE) << "STUN message received, type=" << msg.type;

然后分析日志文件：

grep "ICE" /tmp/webrtc.log | tail -50

3.7 知识体系：编译调试全流程

下面这张图是我自己整理的编译调试全流程，你可以把它当作操作手册：

3.8 实战案例：排查ICE连接超时

最后分享一个我实际遇到的案例。有一次在ARM设备上测试WebRTC通话，ICE连接总是超时。我用了三步定位：

GDB断点：在IceTransport::OnConnectionStateChange处打断点，发现状态一直卡在kChecking。
日志分析：开启RTC_LOG(LS_VERBOSE)，发现STUN请求发送后没有收到响应。
网络排查：用tcpdump抓包，确认是ARM设备的防火墙阻断了UDP 3478端口。

你看，三个工具配合使用，问题很快就定位了。这就是编译调试基本功的价值。