1. 项目缘起：为什么要在ARM上折腾ZLMediaKit？

最近在折腾一个边缘计算的项目，场景是在一个ARM架构的嵌入式工控板上做视频流的汇聚和转发。板子性能不错，跑的是Ubuntu系统，但资源毕竟和x86服务器没法比。最初图省事，直接用了某个轻量级的RTSP服务器，结果在实际压测时，问题就暴露出来了：多路高清流并发一上来，不是卡顿就是直接崩掉，协议兼容性也一般，有些厂家的摄像头死活连不上。

这时候，ZLMediaKit这个名字就跳进了我的视野。它在流媒体服务器圈子里口碑一直很好，以高性能、高并发和丰富的协议支持（RTSP/RTMP/HLS/HTTP-FLV/WebSocket-FLV等）著称，很多互联网直播和安防项目都在用。但翻遍官方文档和社区讨论，发现大家默认的使用场景都是x86_64的Linux服务器或者Windows。关于在ARM平台，特别是资源受限的嵌入式ARM环境下的移植和部署，资料非常零散，几乎都是只言片语。

这不就巧了吗？需求撞上了空白区。把ZLMediaKit这套为高性能服务器设计的“重武器”，成功地移植并优化到ARM平台上，让它稳定、高效地跑起来，就成了一个既有挑战又有实际价值的事情。这不仅仅是跑通一个程序，更涉及到交叉编译工具链的适配、第三方库的依赖处理、针对ARM架构的编译参数调优，以及最终在目标板上的性能验证和问题排查。整个过程，可以说是一步一个坑，但也积累了不少在ARM平台部署复杂C++项目的实战经验。

2. 环境侦察与作战准备：理解你的战场

在开始动手编译之前，盲目地敲命令是最要不得的。我们必须先搞清楚“敌我”形势：我们的开发环境（宿主机）是什么？我们要攻击的目标（目标板）又是什么？这两者之间的桥梁（交叉编译工具链）是否就位？

2.1 明确目标平台与宿主机构型

这是最基础，也最容易出错的一步。ARM平台本身就是一个庞大的家族，从低功耗的Cortex-M系列单片机到高性能的Cortex-A系列应用处理器，架构和指令集都有差异。

• 目标平台 (Target)： 我这次使用的是一块基于Cortex-A72内核的工控板，运行Ubuntu 18.04系统。通过执行uname -m命令，确认其架构为aarch64（即ARM 64位）。这一点至关重要，因为它决定了我们需要寻找或构建对应的交叉编译工具链。如果你的板子是armv7l（32位ARM），那么整个工具链和后续的编译选项都会不同。
• 宿主机 (Host)： 为了编译效率，我选择在一台x86_64的Ubuntu 20.04虚拟机上完成所有编译工作。这构成了典型的交叉编译场景：在X86机器上，生成能在ARM机器上运行的二进制文件。
• 核心任务： 因此，我们的核心就是搭建一套x86_64-linux-gnu 到 aarch64-linux-gnu的交叉编译环境。

2.2 交叉编译工具链的选型与部署

工具链是交叉编译的“武器”。对于aarch64，常见的选择有：

1. Linaro GCC： 老牌且稳定的ARM工具链提供商，社区支持好。
2. ARM官方GCC (Arm GNU Toolchain)： ARM公司自己维护的工具链，更新及时，对ARM新特性支持最好。
3. 目标板系统自带工具链： 有些嵌入式Linux发行版（如Buildroot、Yocto定制出的系统）会提供配套的SDK，里面就包含了完美的交叉编译工具链。这是最推荐的方式，因为它和板子上运行的系统库版本完全一致，能最大程度避免兼容性问题。

我这次很幸运，板子供应商提供了一个完整的SDK。如果没有，从ARM官网下载是最稳妥的选择。以下以ARM官方工具链为例，展示部署过程：

# 1. 在宿主机上，创建工具链目录并下载（请替换为最新版本链接） mkdir -p /opt/toolchains cd /opt/toolchains wget https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/arm-gnu-toolchain-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz # 2. 解压 tar -xf arm-gnu-toolchain-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz # 3. 将工具链路径加入系统环境变量，方便调用 echo 'export PATH=/opt/toolchains/arm-gnu-toolchain-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin:$PATH' >> ~/.bashrc source ~/.bashrc # 4. 验证工具链是否安装成功 aarch64-none-linux-gnu-gcc --version

如果成功输出了gcc的版本信息，并且前缀是aarch64-none-linux-gnu-，那么恭喜你，最关键的武器已经到手了。

注意： 不同工具链的“前缀（prefix）”可能不同，例如可能是aarch64-linux-gnu-或aarch64-buildroot-linux-gnu-。后续所有的CC、CXX环境变量以及configure、cmake参数都需要使用这个正确的前缀。用ls /opt/toolchains/你的工具链目录/bin/查看一下就能确认。

2.3 ZLMediaKit源码与依赖库分析

工欲善其事，必先利其器。接下来，我们需要把ZLMediaKit的“图纸”和“零部件”准备好。

# 克隆ZLMediaKit源码及子模块（非常重要！） git clone --depth 1 https://github.com/ZLMediaKit/ZLMediaKit.git cd ZLMediaKit git submodule update --init --recursive

ZLMediaKit依赖于几个关键的第三方库，这部分是移植的重点和难点：

• OpenSSL： 用于TLS/DTLS加密，RTMPS等协议必需。
• libsrtp： 用于SRTP加密，WebRTC流传输必需。
• ffmpeg： 用于转码、复用/解复用。如果只需要流转发而不需要转码，可以在编译时关闭此特性。
• usrsctp： 用于SCTP协议，WebRTC数据通道必需。

核心矛盾在于：ZLMediaKit的编译脚本默认会从网络下载预编译好的x86_64版本的这些依赖库，这显然不符合我们交叉编译的需求。我们必须手动为ARM平台交叉编译这些依赖库，或者确保目标板上已经安装了这些库的ARM版本。

3. 攻坚战：交叉编译依赖库与ZLMediaKit

这是整个移植过程最核心、最繁琐的环节。我们的策略是：在宿主机上，使用交叉编译工具链，为ARM目标板编译所有必需的依赖库，并安装到某个特定的目录（例如/opt/arm-libs）下。然后，在编译ZLMediaKit时，告诉它去这个目录里找ARM版本的库和头文件。

3.1 交叉编译OpenSSL

OpenSSL的交叉编译需要仔细配置。

# 在宿主机上操作 cd /path/to/your/workdir wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz # 下载稳定版本，版本号请更新 tar -zxf openssl-1.1.1w.tar.gz cd openssl-1.1.1w # 配置交叉编译参数 ./Configure linux-aarch64 \ --prefix=/opt/arm-libs/openssl \ # 指定安装路径 --cross-compile-prefix=aarch64-none-linux-gnu- \ # 你的工具链前缀 no-shared \ # 静态链接，避免运行时依赖问题，简化部署 no-asm \ # 如果不确定目标板汇编兼容性，可以先关闭 no-dso \ no-engine # 编译并安装 make -j$(nproc) make install

编译完成后，/opt/arm-libs/openssl目录下就会有include和lib子目录，里面就是ARM架构的OpenSSL文件。

3.2 交叉编译其他依赖（以libsrtp为例）

其他库的流程类似，核心都是设置正确的--host、--prefix和环境变量。

# 编译libsrtp cd /path/to/your/workdir git clone https://github.com/cisco/libsrtp.git cd libsrtp ./configure --host=aarch64-none-linux-gnu \ # 指定目标主机类型 --prefix=/opt/arm-libs/libsrtp \ --enable-openssl \ --with-openssl-dir=/opt/arm-libs/openssl # 指向我们刚编译的OpenSSL make -j$(nproc) make install

对于ffmpeg，交叉编译的配置更为复杂，通常需要写一个详细的配置脚本来启用或禁用众多编解码器和特性。如果不需要转码功能，在ZLMediaKit中关闭FFmpeg支持是更简单的方法。

3.3 交叉编译ZLMediaKit本体

依赖库准备就绪后，终于可以编译主角了。ZLMediaKit使用CMake构建，我们需要通过一个工具链文件（Toolchain File）来告诉CMake所有交叉编译的设定。

1. 创建工具链文件arm_toolchain.cmake：

# arm_toolchain.cmake set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) # 指定交叉编译工具链前缀 set(TOOLCHAIN_PREFIX "aarch64-none-linux-gnu-") set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}g++) # 指定目标环境根目录（即我们存放ARM库的地方） set(CMAKE_FIND_ROOT_PATH /opt/arm-libs) # 只在目标根目录中查找库和头文件 set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

2. 配置和编译ZLMediaKit：

cd /path/to/ZLMediaKit mkdir -p build_arm cd build_arm # 使用工具链文件进行配置 cmake .. \ -DCMAKE_TOOLCHAIN_FILE=../arm_toolchain.cmake \ -DCMAKE_INSTALL_PREFIX=/opt/arm-libs/zlm \ -DENABLE_WEBRTC=ON \ -DOPENSSL_ROOT_DIR=/opt/arm-libs/openssl \ -DOPENSSL_LIBRARIES=/opt/arm-libs/openssl/lib \ -DOPENSSL_INCLUDE_DIR=/opt/arm-libs/openssl/include \ -DENABLE_FFMPEG=OFF \ # 根据需求开关，关闭可简化编译 -DCMAKE_BUILD_TYPE=Release # 开始编译 make -j$(nproc)

这个过程可能会比较长，并且可能会遇到各种依赖路径找不到的错误。你需要根据CMake的报错信息，灵活地通过-Dxxx_DIR或-Dxxx_LIBRARY、-Dxxx_INCLUDE_DIR等参数，将我们之前编译好的ARM库的路径一一指定给CMake。

4. 战场移交与实战部署：让服务在ARM板跑起来

编译成功，在build_arm目录下会生成MediaServer这个可执行文件。用file命令检查一下：

file MediaServer

输出应该是MediaServer: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux)...，这确认了它是ARM 64位程序。

4.1 部署到目标板

将编译产物拷贝到ARM开发板上。你需要将以下内容打包：

• MediaServer可执行文件。
• 相关的配置文件（config.ini,default.pem等，从源码目录conf/下获取）。
• 所有依赖的动态库（.so文件）。这是最容易出问题的地方。

可以使用ldd命令在宿主机上检查MediaServer的依赖（注意，需要用工具链里的ldd，或者用aarch64-none-linux-gnu-readelf -d MediaServer | grep NEEDED查看）。

# 在宿主机上，使用工具链的readelf aarch64-none-linux-gnu-readelf -d MediaServer | grep NEEDED

然后，去/opt/arm-libs下对应的lib目录里，找到这些.so文件，一并拷贝到目标板的某个目录（例如/opt/zlm/lib）。最后，在目标板上，通过设置LD_LIBRARY_PATH环境变量，让程序能找到这些库。

# 在ARM目标板上操作 export LD_LIBRARY_PATH=/opt/zlm/lib:$LD_LIBRARY_PATH cd /opt/zlm ./MediaServer -c config.ini -s ./ssl.pem &

4.2 常见问题与排坑指南

1. “找不到符号”或“版本`GLIBCXX_3.4.29’未找到”：

   • 原因： 宿主机交叉编译工具链的C++标准库版本高于目标板系统自带的版本。
   • 解决： 这是交叉编译的经典难题。有两种思路：一是降低宿主机工具链的版本，使其与目标板系统匹配；二是将工具链中的对应C++标准库（如libstdc++.so.6）也拷贝到目标板的LD_LIBRARY_PATH目录下。更推荐静态链接C++标准库，在CMake配置时加上-DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++"，这样可以彻底摆脱对目标板系统库版本的依赖。

2. 程序启动后秒退或无响应：

   • 原因： 配置文件路径错误、依赖库没找到、或者端口被占用。
   • 排查： 首先在目标板上运行./MediaServer -c config.ini -d（-d参数在前台运行并输出日志），观察控制台输出的错误信息。检查日志文件logs/下的内容。用netstat -tlnp检查ZLMediaKit默认的端口（如1935、554、80、443等）是否已被占用。

3. 性能不佳：

   • 原因： ARM平台的CPU和内存带宽通常弱于服务器。默认配置可能不适合。
   • 优化： 编辑config.ini，根据板子核心数调整threads相关配置（如general.thread_num）。对于视频流，可以尝试关闭不必要协议（如HLS）以减少开销。如果只是做流转发，确保ENABLE_FFMPEG=OFF，避免编解码消耗大量CPU。

5. 进阶思考：从“能用”到“好用”

当服务稳定跑起来后，我们可以考虑更多生产环境的问题。

5.1 系统服务化通过编写systemd服务文件，让ZLMediaKit能够开机自启、崩溃重启、方便地查看日志。

# /etc/systemd/system/zlm.service [Unit] Description=ZLMediaKit Media Server After=network.target [Service] Type=simple User=root WorkingDirectory=/opt/zlm ExecStart=/opt/zlm/MediaServer -c /opt/zlm/config.ini -m 3 Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

然后使用systemctl enable --now zlm启用服务。

5.2 资源监控与告警对于嵌入式设备，资源监控尤为重要。可以编写简单的脚本，定期检查MediaServer进程的CPU、内存占用，以及网络连接数。结合crontab和邮件/短信网关，实现异常告警。

5.3 针对特定硬件的优化如果ARM板子有GPU或专用的视频编解码硬件（如RK3568/RK3588的NPU、Jetson系列的NVDEC/NVENC），ZLMediaKit的默认FFmpeg可能无法调用。这就需要深入下去，编译开启了对应硬件加速支持的FFmpeg，并集成到ZLMediaKit中。这又是一个复杂的专项任务，但能极大提升性能和解码路数。

整个移植过程，就像是一场精心策划的战役。从环境侦察、武器（工具链）准备，到逐个攻破依赖库的堡垒，最后完成主程序的编译和部署，每一步都需要耐心和细致。最大的体会就是：交叉编译的问题，90%都出在环境变量和路径上。保持清晰的思路，用好--prefix、CMAKE_PREFIX_PATH、LD_LIBRARY_PATH这些“路标”，遇到错误时仔细阅读输出信息，大部分难关都能攻克。最终看到自己编译的MediaServer在ARM板上流畅地推送出视频流时，那种成就感，就是对我们这些“底层”工程师最好的回馈。