简介librtmp库作为rtmpdump工具的核心组件长期用于RTMP协议处理与实时流媒体开发。该librtmp库实测可在Linux环境下完成交叉编译面向需要在x86开发机上为ARM等嵌入式平台构建RTMP库的开发者可帮助解决编译链配置与Makefile调整等常见问题。压缩包共106个文件以86个.h头文件为主另含6个.lib库文件、5个.c源码、Makefile及相关工程配置文件整体大小4.35MB便于直接对照学习。目前已有1421人学习下载具备一定参考价值。资源中包含librtmp、amf、hashswf、parseurl、log等关键模块实现从RTMP握手、AMF编解码到数据收发均有涉及读者既能借此厘清协议细节也能利用预编译库快速集成或按需交叉编译到目标平台尤其适合嵌入式流媒体项目前期预研与实战排错参考。对于需要移植到嵌入式场景的团队而言这份资源提供了完整的编译参考和模块划分可大幅减少重复排查时间。 做嵌入式流媒体传输的朋友应该都绕不过 librtmp 这个库。网络摄像头、机顶盒、ARM 开发板只要是做 RTMP 推流或者拉流这套开源的 RTMP 客户端库几乎是默认首选。最近我手头一个飞腾 ARM 平台的视频推送项目需要把原来在 x86 环境里跑得好好的 RTMP 客户端整体迁移过去于是把 librtmp 在 Linux 下交叉编译的完整流程走了一遍。整个过程比预想中要绕不少主要卡在依赖库的交叉编译和工具链的细节上这里把实操过程和踩坑记录整理出来希望能帮你省下半天时间。1. 交叉编译 librtmp 之前先想清楚这几件事1.1 交叉编译的基本逻辑所谓交叉编译就是在当前这台 x86_64 的 Linux 编译机上用一套目标平台的工具链编译出在 ARM 架构处理器上运行的二进制文件。之所以不能直接在开发板上编译一是大多数嵌入式设备的算力、内存都比较有限编译大型库会非常慢二是很多产品的主控上根本没有完整的编译环境只有精简的运行时。我自己的习惯是主机用 Ubuntu 20.04 或 22.04目标平台是 64 位 ARM 的用 aarch64 工具链32 位 ARM 的用 arm-linux-gnueabihf 工具链。这里要注意硬浮点和软浮点的区别现在绝大多数新的 ARM 平台都是硬浮点选工具链时带hf的基本不会错。但如果是老内核、老根文件系统的设备还是要先确认目标板的 ABI 和浮点参数否则编译出来的程序一运行就直接报 Illegal instruction 或者找不到加载器这种问题排查起来非常痛苦因为编译阶段完全察觉不到。1.2 librtmp 的依赖关系决定了编译顺序很多人以为编译 librtmp 就是进到源码目录一条 make 的事实际不是。librtmp 的底层依赖 OpenSSL 做 TLS 加密握手依赖 zlib 处理压缩数据所以编译顺序必须从底层依赖往上排先编 zlib再编 OpenSSL最后编 librtmp。反过来先编 librtmp编译器会直接告诉你头文件找不到而且报错位置很迷惑有时候是 ssl.h 找不到有时候是 zlib.h 的问题新手很容易误以为 librtmp 源码有问题。这个依赖关系也解释了为什么官方仓库里提供的预编译二进制包不能直接用目标板上如果没有对应的.so程序跑起来会报error while loading shared libraries。所以我建议一开始就把三个库的 install 目录规划好统一放在一个目录里后面写 Makefile 和链接参数都会省事很多。2. 环境准备与工具链选型2.1 主机环境与工具链安装我这次的主机是 Ubuntu 22.04x86_64 架构目标板是飞腾 FT-2000/464 位 ARM 架构。工具链我直接用了 Ubuntu 自带的交叉编译包没有额外去装 Linaro。安装命令很简单# 64位 ARM sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 32位 ARM根据目标平台选择 sudo apt install gcc-arm-linux-gnueabihf g-arm-linux-gnueabihf安装完记得验证一下工具链版本确保环境变量和 PATH 没有问题aarch64-linux-gnu-gcc -v如果项目里明确指定要用 Linaro 的交叉编译工具链那就需要去官方镜像站下载对应版本的压缩包解压后把bin目录加入 PATH。相比 Ubuntu 仓库里的版本Linaro 工具链在某些老内核目标板上的兼容性确实更好但引入方式更繁琐交叉编译时所有路径都要手动指定很考验环境配置的细心程度。我自己实际跑下来如果目标板内核版本不是特别老4.x 以上直接用 Ubuntu 自带的 aarch64-linux-gnu 完全够用。2.2 整理目录结构我习惯把所有交叉编译产物放到一个独立的目录里避免污染主机环境也方便后面打包发给其他同事。这里给一个参考结构export ROOT_DIR$HOME/cross_build export SYSROOT$ROOT_DIR/sysroot-aarch64 mkdir -p $SYSROOT/{lib,include} $ROOT_DIR/{zlib,openssl,librtmp}后面所有库的 install 路径都指向$SYSROOT最后把整个sysroot-aarch64目录拷到开发板或者打包进根文件系统依赖关系就非常清晰了。很多人交叉编译习惯把库装到默认的/usr/local这样虽然能编过但产物里全是主机路径部署到板子上就必须重新整理一遍反而更浪费时间。3. 依赖库的交叉编译完整流程3.1 第一个依赖zlibzlib 的交叉编译是所有依赖里最简单的它没有那种复杂的 configure 检测脚本主要就是设置 CC 和 AR 环境变量然后走 Makefile 的交叉编译分支。我使用的是 zlib 1.2.13目前 1.2.x 系列里比较新的版本和 librtmp、OpenSSL 1.1.1 都兼容。cd $ROOT_DIR/zlib wget https://zlib.net/zlib-1.2.13.tar.gz tar zxf zlib-1.2.13.tar.gz cd zlib-1.2.13 export CCaarch64-linux-gnu-gcc export ARaarch64-linux-gnu-ar ./configure --prefix$SYSROOT --static make -j$(nproc) make install这里我特意加了--static是因为 librtmp 链接 zlib 时用静态库可以减少目标板上动态库的数量。不过要注意--static只对 zlib 生效OpenSSL 那边不建议全静态编译原因后面会细说。另外提醒一句make install完成后最好把环境变量 CC、AR 清理掉避免影响后面 OpenSSL 的配置。3.2 第二个依赖OpenSSL 1.1.1OpenSSL 的交叉编译比 zlib 容易踩坑。我强烈建议用 OpenSSL 1.1.1 系列的最新版比如 1.1.1w不要用 OpenSSL 3.x。原因很简单librtmp 的老代码大量使用 OpenSSL 1.1 的 API3.x 里不少接口废弃或者改成了宏编译时会有一堆函数不可用的报错就算强行编过代码里也要额外加兼容层完全没有必要。编译命令如下cd $ROOT_DIR/openssl 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$SYSROOT \ --cross-compile-prefixaarch64-linux-gnu- \ no-asm \ shared \ -fPIC make -j$(nproc) make install几个关键参数的作用我逐个说一下。linux-aarch64是 OpenSSL 预定义的目标平台配置名称32 位 ARM 要用linux-armv4这个配置决定了 OpenSSL 内部编译哪些架构相关的代码。--cross-compile-prefix指定交叉工具链前缀后面 make 时 OpenSSL 会自动拼接出aarch64-linux-gnu-gcc这样的完整命令。no-asm关闭汇编优化。这一步是我最容易漏的嵌入式目标板的汇编指令集和 x86 完全不同OpenSSL 的 asm 代码在某些精简工具链上会因为汇编器版本过老或者指令不匹配而失败。关了之后只是加解密性能略有下降对 RTMP 推流这种场景完全感知不到。shared生成动态库同时加-fPIC确保后续链接进 librtmp 的.so时不会报位置无关代码相关的错误。3.3 第三个步骤librtmp 本身librtmp 的源码在 rtmpdump 项目仓库里clone 或者下载 release 包都可以cd $ROOT_DIR/librtmp git clone https://git.ffmpeg.org/rtmpdump cd rtmpdump/librtmplibrtmp 的 Makefile 支持CROSS_COMPILE变量不需要手动去改源码把编译参数一次性传进去就行。我最后的编译命令长这样make clean make \ CROSS_COMPILEaarch64-linux-gnu- \ CRYPTOOPENSSL \ XCFLAGS-I$SYSROOT/include \ XLDFLAGS-L$SYSROOT/lib \ prefix$SYSROOT \ SHAREDyes \ -j$(nproc)编译完执行make install参数含义解释一下CRYPTOOPENSSL告诉 librtmp 使用 OpenSSL 作为加密后端。如果你用的是 mbedTLS可以改成CRYPTOMBEDTLS但要重新配置 XCFLAGS 和 XLDFLAGS。XCFLAGS-I$SYSROOT/include让编译时能找到 zlib 和 OpenSSL 的头文件。XLDFLAGS-L$SYSROOT/lib让链接时能找到 zlib 和 OpenSSL 的库文件。SHAREDyes生成动态库librtmp.so。如果目标板内存特别紧张也可以SHAREDno只编静态库按需选择。编完之后验证一下产物架构file $SYSROOT/lib/librtmp.so看到输出里有ARM aarch64字样就说明交叉编译这一步成功了。4. 把编译结果集成到项目里4.1 准备一个测试程序验证只编译出库还不够至少要写一个小的测试程序跑通推流或拉流链路才能确认 librtmp 的 API 调用、OpenSSL 的链接、目标板的动态加载都没有问题。我在实际项目里会先写一个最简单的 RTMP 拉流程序核心就三个接口RTMP_Init、RTMP_Connect、RTMP_Read。编译时直接用交叉编译器链接aarch64-linux-gnu-gcc -o rtmp_test rtmp_test.c \ -I$SYSROOT/include \ -L$SYSROOT/lib \ -lrtmp -lssl -lcrypto -lz -ldl -lpthread这里特别要注意链接顺序要把-lrtmp写在依赖库前面。链接器是从左往右扫描的如果-lrtmp写在最后一旦 librtmp 里有引用 OpenSSL 的符号链接器可能已经错过了 OpenSSL 的库就会报一堆 undefined reference这种问题定位起来很迷惑其实是链接顺序不对。4.2 部署到开发板测试程序编译好之后用 scp、U 盘或者 adb 拷到开发板上。动态库也要一并拷贝我把$SYSROOT/lib下的libz.so、libssl.so、libcrypto.so、librtmp.so都放到了开发板的/usr/lib或者自定义的库目录然后设置LD_LIBRARY_PATH指向该目录。如果目标板上已经有系统自带的 OpenSSL最好先看一下版本老版本系统里通常还是 1.0.2 或者 1.1.1和编译时如果一致可以尽量复用不一致就直接用我们编好的.so避免加载混乱。4.3 在开发板上验证跑一下测试程序./rtmp_test rtmp://192.168.1.100/live/test如果库路径没问题程序就能正常连接 RTMP 服务器并拉取数据。如果报symbol lookup error通常是你目标板上的 OpenSSL 版本和编译时的不一致需要把配套的.so一起覆盖过去不要让程序去加载系统自带的旧版本 OpenSSL。如果报No such file or directory那基本就是动态加载器版本不匹配的问题这个后面详细说。5. 交叉编译高频问题与排查实录5.1 openssl/ssl.h 头文件找不到这个报错是头文件路径没指对。先确认 OpenSSL 是否安装到了$SYSROOT/include再看 Makefile 里的XCFLAGS是否包含了-I$SYSROOT/include。如果路径写对了还找不到用find $SYSROOT -name ssl.h查一下头文件实际位置OpenSSL 的 install 路径有时候会因为 Configure 参数差异落在意外的地方。5.2 链接时大量 undefined reference这是我遇到最多的坑几乎都是 OpenSSL 3.x 导致。报错信息类似下面这样undefined reference to SSL_library_init undefined reference to OpenSSL_add_all_algorithmsSSL_library_init在 OpenSSL 1.1 里已经变成宏3.x 里直接废弃了。librtmp 老版本代码调用的还是旧 API。解决办法只有一个换回 OpenSSL 1.1.1 重新编译不要尝试改 librtmp 源码去适配 3.x。真要适配 3.x牵涉的接口改动远不止这一两处成本完全不值得。5.3 编译 OpenSSL 时汇编语法错误如果碰到类似.arch armv8-acrypto的汇编指令报错十有八九是新工具链编旧源码时 OpenSSL 的 asm 优化触发了兼容性问题。解决方式就是在 Configure 阶段加no-asm其他参数都不用动。5.4 程序放到开发板报 /lib/ld-linux-aarch64.so.1: No such file or directory这个报错说明你编译用的工具链对应的 glibc 版本比目标板根文件系统的 glibc 高程序在板子上找不到匹配的动态加载器。处理方式有两个一是换成与目标板系统匹配的旧版工具链二是升级目标板的根文件系统。如果产品已经量产改根文件系统不现实那只能老老实实找和老系统 glibc 匹配的工具链版本。排查命令用 readelf 看程序的动态加载器aarch64-linux-gnu-readelf -l rtmp_test | grep interpreter然后对比板子上/lib下实际存在的加载器文件。5.5 编译时报需要重新编译带 -fPIC 的错误编译 librtmp 时如果收到类似recompile with -fPIC的错误说明依赖库编译时没有加-fPIC导致它们无法被合并进 librtmp 的共享库。解决方法是把 zlib、OpenSSL 的编译选项里加上-fPIC重新编译。很多人在这里反复折腾其实就是最开始没给依赖库加位置无关代码参数。6. 实践中的几个额外建议除了上面的具体步骤我再补充几个实践中的判断依据。工具链方面不用过度迷信某个特定版本。我建议先用 Ubuntu 自带的交叉工具链快速跑通全流程确认代码能编译、板子能运行再回头考虑是不是要换 Linaro 或其他定制工具链。先用最简单的方案验证比一开始就纠结工具链版本要高效得多。依赖库版本方面zlib 选 1.2.12 或 1.2.13 都可以OpenSSL 尽量用 1.1.1 系列的最新小版本。版本太老会有安全告警版本太新和 librtmp 的 API 兼容性又容易出问题1.1.1 是当前最稳妥的选择。至于 librtmp 本身直接拉 rtmpdump 仓库的 master 分支一般没问题这是社区长期维护的活跃仓库比找几个镜像站的老 release 包更可靠。集成方面如果你的项目里还要用 Qt 或者 ffmpeg思路是一样的先保证这三个库的交叉编译产物齐全再向外扩展。librtmp 只是整个链路的一环把依赖和工具链理清楚后面编什么都顺。最后再分享一个我特别推荐的检查习惯编译完不管是什么架构的库和程序都先用file和readelf确认当前架构和依赖拷贝到板子之前就排查掉一半的问题。等上了板子再排查调试成本高出好几倍不说还容易让人怀疑是硬件或系统层面的问题白白浪费时间。本文还有配套的精品资源点击获取
嵌入式Linux下librtmp交叉编译实战：从依赖到部署
简介librtmp库作为rtmpdump工具的核心组件长期用于RTMP协议处理与实时流媒体开发。该librtmp库实测可在Linux环境下完成交叉编译面向需要在x86开发机上为ARM等嵌入式平台构建RTMP库的开发者可帮助解决编译链配置与Makefile调整等常见问题。压缩包共106个文件以86个.h头文件为主另含6个.lib库文件、5个.c源码、Makefile及相关工程配置文件整体大小4.35MB便于直接对照学习。目前已有1421人学习下载具备一定参考价值。资源中包含librtmp、amf、hashswf、parseurl、log等关键模块实现从RTMP握手、AMF编解码到数据收发均有涉及读者既能借此厘清协议细节也能利用预编译库快速集成或按需交叉编译到目标平台尤其适合嵌入式流媒体项目前期预研与实战排错参考。对于需要移植到嵌入式场景的团队而言这份资源提供了完整的编译参考和模块划分可大幅减少重复排查时间。 做嵌入式流媒体传输的朋友应该都绕不过 librtmp 这个库。网络摄像头、机顶盒、ARM 开发板只要是做 RTMP 推流或者拉流这套开源的 RTMP 客户端库几乎是默认首选。最近我手头一个飞腾 ARM 平台的视频推送项目需要把原来在 x86 环境里跑得好好的 RTMP 客户端整体迁移过去于是把 librtmp 在 Linux 下交叉编译的完整流程走了一遍。整个过程比预想中要绕不少主要卡在依赖库的交叉编译和工具链的细节上这里把实操过程和踩坑记录整理出来希望能帮你省下半天时间。1. 交叉编译 librtmp 之前先想清楚这几件事1.1 交叉编译的基本逻辑所谓交叉编译就是在当前这台 x86_64 的 Linux 编译机上用一套目标平台的工具链编译出在 ARM 架构处理器上运行的二进制文件。之所以不能直接在开发板上编译一是大多数嵌入式设备的算力、内存都比较有限编译大型库会非常慢二是很多产品的主控上根本没有完整的编译环境只有精简的运行时。我自己的习惯是主机用 Ubuntu 20.04 或 22.04目标平台是 64 位 ARM 的用 aarch64 工具链32 位 ARM 的用 arm-linux-gnueabihf 工具链。这里要注意硬浮点和软浮点的区别现在绝大多数新的 ARM 平台都是硬浮点选工具链时带hf的基本不会错。但如果是老内核、老根文件系统的设备还是要先确认目标板的 ABI 和浮点参数否则编译出来的程序一运行就直接报 Illegal instruction 或者找不到加载器这种问题排查起来非常痛苦因为编译阶段完全察觉不到。1.2 librtmp 的依赖关系决定了编译顺序很多人以为编译 librtmp 就是进到源码目录一条 make 的事实际不是。librtmp 的底层依赖 OpenSSL 做 TLS 加密握手依赖 zlib 处理压缩数据所以编译顺序必须从底层依赖往上排先编 zlib再编 OpenSSL最后编 librtmp。反过来先编 librtmp编译器会直接告诉你头文件找不到而且报错位置很迷惑有时候是 ssl.h 找不到有时候是 zlib.h 的问题新手很容易误以为 librtmp 源码有问题。这个依赖关系也解释了为什么官方仓库里提供的预编译二进制包不能直接用目标板上如果没有对应的.so程序跑起来会报error while loading shared libraries。所以我建议一开始就把三个库的 install 目录规划好统一放在一个目录里后面写 Makefile 和链接参数都会省事很多。2. 环境准备与工具链选型2.1 主机环境与工具链安装我这次的主机是 Ubuntu 22.04x86_64 架构目标板是飞腾 FT-2000/464 位 ARM 架构。工具链我直接用了 Ubuntu 自带的交叉编译包没有额外去装 Linaro。安装命令很简单# 64位 ARM sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 32位 ARM根据目标平台选择 sudo apt install gcc-arm-linux-gnueabihf g-arm-linux-gnueabihf安装完记得验证一下工具链版本确保环境变量和 PATH 没有问题aarch64-linux-gnu-gcc -v如果项目里明确指定要用 Linaro 的交叉编译工具链那就需要去官方镜像站下载对应版本的压缩包解压后把bin目录加入 PATH。相比 Ubuntu 仓库里的版本Linaro 工具链在某些老内核目标板上的兼容性确实更好但引入方式更繁琐交叉编译时所有路径都要手动指定很考验环境配置的细心程度。我自己实际跑下来如果目标板内核版本不是特别老4.x 以上直接用 Ubuntu 自带的 aarch64-linux-gnu 完全够用。2.2 整理目录结构我习惯把所有交叉编译产物放到一个独立的目录里避免污染主机环境也方便后面打包发给其他同事。这里给一个参考结构export ROOT_DIR$HOME/cross_build export SYSROOT$ROOT_DIR/sysroot-aarch64 mkdir -p $SYSROOT/{lib,include} $ROOT_DIR/{zlib,openssl,librtmp}后面所有库的 install 路径都指向$SYSROOT最后把整个sysroot-aarch64目录拷到开发板或者打包进根文件系统依赖关系就非常清晰了。很多人交叉编译习惯把库装到默认的/usr/local这样虽然能编过但产物里全是主机路径部署到板子上就必须重新整理一遍反而更浪费时间。3. 依赖库的交叉编译完整流程3.1 第一个依赖zlibzlib 的交叉编译是所有依赖里最简单的它没有那种复杂的 configure 检测脚本主要就是设置 CC 和 AR 环境变量然后走 Makefile 的交叉编译分支。我使用的是 zlib 1.2.13目前 1.2.x 系列里比较新的版本和 librtmp、OpenSSL 1.1.1 都兼容。cd $ROOT_DIR/zlib wget https://zlib.net/zlib-1.2.13.tar.gz tar zxf zlib-1.2.13.tar.gz cd zlib-1.2.13 export CCaarch64-linux-gnu-gcc export ARaarch64-linux-gnu-ar ./configure --prefix$SYSROOT --static make -j$(nproc) make install这里我特意加了--static是因为 librtmp 链接 zlib 时用静态库可以减少目标板上动态库的数量。不过要注意--static只对 zlib 生效OpenSSL 那边不建议全静态编译原因后面会细说。另外提醒一句make install完成后最好把环境变量 CC、AR 清理掉避免影响后面 OpenSSL 的配置。3.2 第二个依赖OpenSSL 1.1.1OpenSSL 的交叉编译比 zlib 容易踩坑。我强烈建议用 OpenSSL 1.1.1 系列的最新版比如 1.1.1w不要用 OpenSSL 3.x。原因很简单librtmp 的老代码大量使用 OpenSSL 1.1 的 API3.x 里不少接口废弃或者改成了宏编译时会有一堆函数不可用的报错就算强行编过代码里也要额外加兼容层完全没有必要。编译命令如下cd $ROOT_DIR/openssl 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$SYSROOT \ --cross-compile-prefixaarch64-linux-gnu- \ no-asm \ shared \ -fPIC make -j$(nproc) make install几个关键参数的作用我逐个说一下。linux-aarch64是 OpenSSL 预定义的目标平台配置名称32 位 ARM 要用linux-armv4这个配置决定了 OpenSSL 内部编译哪些架构相关的代码。--cross-compile-prefix指定交叉工具链前缀后面 make 时 OpenSSL 会自动拼接出aarch64-linux-gnu-gcc这样的完整命令。no-asm关闭汇编优化。这一步是我最容易漏的嵌入式目标板的汇编指令集和 x86 完全不同OpenSSL 的 asm 代码在某些精简工具链上会因为汇编器版本过老或者指令不匹配而失败。关了之后只是加解密性能略有下降对 RTMP 推流这种场景完全感知不到。shared生成动态库同时加-fPIC确保后续链接进 librtmp 的.so时不会报位置无关代码相关的错误。3.3 第三个步骤librtmp 本身librtmp 的源码在 rtmpdump 项目仓库里clone 或者下载 release 包都可以cd $ROOT_DIR/librtmp git clone https://git.ffmpeg.org/rtmpdump cd rtmpdump/librtmplibrtmp 的 Makefile 支持CROSS_COMPILE变量不需要手动去改源码把编译参数一次性传进去就行。我最后的编译命令长这样make clean make \ CROSS_COMPILEaarch64-linux-gnu- \ CRYPTOOPENSSL \ XCFLAGS-I$SYSROOT/include \ XLDFLAGS-L$SYSROOT/lib \ prefix$SYSROOT \ SHAREDyes \ -j$(nproc)编译完执行make install参数含义解释一下CRYPTOOPENSSL告诉 librtmp 使用 OpenSSL 作为加密后端。如果你用的是 mbedTLS可以改成CRYPTOMBEDTLS但要重新配置 XCFLAGS 和 XLDFLAGS。XCFLAGS-I$SYSROOT/include让编译时能找到 zlib 和 OpenSSL 的头文件。XLDFLAGS-L$SYSROOT/lib让链接时能找到 zlib 和 OpenSSL 的库文件。SHAREDyes生成动态库librtmp.so。如果目标板内存特别紧张也可以SHAREDno只编静态库按需选择。编完之后验证一下产物架构file $SYSROOT/lib/librtmp.so看到输出里有ARM aarch64字样就说明交叉编译这一步成功了。4. 把编译结果集成到项目里4.1 准备一个测试程序验证只编译出库还不够至少要写一个小的测试程序跑通推流或拉流链路才能确认 librtmp 的 API 调用、OpenSSL 的链接、目标板的动态加载都没有问题。我在实际项目里会先写一个最简单的 RTMP 拉流程序核心就三个接口RTMP_Init、RTMP_Connect、RTMP_Read。编译时直接用交叉编译器链接aarch64-linux-gnu-gcc -o rtmp_test rtmp_test.c \ -I$SYSROOT/include \ -L$SYSROOT/lib \ -lrtmp -lssl -lcrypto -lz -ldl -lpthread这里特别要注意链接顺序要把-lrtmp写在依赖库前面。链接器是从左往右扫描的如果-lrtmp写在最后一旦 librtmp 里有引用 OpenSSL 的符号链接器可能已经错过了 OpenSSL 的库就会报一堆 undefined reference这种问题定位起来很迷惑其实是链接顺序不对。4.2 部署到开发板测试程序编译好之后用 scp、U 盘或者 adb 拷到开发板上。动态库也要一并拷贝我把$SYSROOT/lib下的libz.so、libssl.so、libcrypto.so、librtmp.so都放到了开发板的/usr/lib或者自定义的库目录然后设置LD_LIBRARY_PATH指向该目录。如果目标板上已经有系统自带的 OpenSSL最好先看一下版本老版本系统里通常还是 1.0.2 或者 1.1.1和编译时如果一致可以尽量复用不一致就直接用我们编好的.so避免加载混乱。4.3 在开发板上验证跑一下测试程序./rtmp_test rtmp://192.168.1.100/live/test如果库路径没问题程序就能正常连接 RTMP 服务器并拉取数据。如果报symbol lookup error通常是你目标板上的 OpenSSL 版本和编译时的不一致需要把配套的.so一起覆盖过去不要让程序去加载系统自带的旧版本 OpenSSL。如果报No such file or directory那基本就是动态加载器版本不匹配的问题这个后面详细说。5. 交叉编译高频问题与排查实录5.1 openssl/ssl.h 头文件找不到这个报错是头文件路径没指对。先确认 OpenSSL 是否安装到了$SYSROOT/include再看 Makefile 里的XCFLAGS是否包含了-I$SYSROOT/include。如果路径写对了还找不到用find $SYSROOT -name ssl.h查一下头文件实际位置OpenSSL 的 install 路径有时候会因为 Configure 参数差异落在意外的地方。5.2 链接时大量 undefined reference这是我遇到最多的坑几乎都是 OpenSSL 3.x 导致。报错信息类似下面这样undefined reference to SSL_library_init undefined reference to OpenSSL_add_all_algorithmsSSL_library_init在 OpenSSL 1.1 里已经变成宏3.x 里直接废弃了。librtmp 老版本代码调用的还是旧 API。解决办法只有一个换回 OpenSSL 1.1.1 重新编译不要尝试改 librtmp 源码去适配 3.x。真要适配 3.x牵涉的接口改动远不止这一两处成本完全不值得。5.3 编译 OpenSSL 时汇编语法错误如果碰到类似.arch armv8-acrypto的汇编指令报错十有八九是新工具链编旧源码时 OpenSSL 的 asm 优化触发了兼容性问题。解决方式就是在 Configure 阶段加no-asm其他参数都不用动。5.4 程序放到开发板报 /lib/ld-linux-aarch64.so.1: No such file or directory这个报错说明你编译用的工具链对应的 glibc 版本比目标板根文件系统的 glibc 高程序在板子上找不到匹配的动态加载器。处理方式有两个一是换成与目标板系统匹配的旧版工具链二是升级目标板的根文件系统。如果产品已经量产改根文件系统不现实那只能老老实实找和老系统 glibc 匹配的工具链版本。排查命令用 readelf 看程序的动态加载器aarch64-linux-gnu-readelf -l rtmp_test | grep interpreter然后对比板子上/lib下实际存在的加载器文件。5.5 编译时报需要重新编译带 -fPIC 的错误编译 librtmp 时如果收到类似recompile with -fPIC的错误说明依赖库编译时没有加-fPIC导致它们无法被合并进 librtmp 的共享库。解决方法是把 zlib、OpenSSL 的编译选项里加上-fPIC重新编译。很多人在这里反复折腾其实就是最开始没给依赖库加位置无关代码参数。6. 实践中的几个额外建议除了上面的具体步骤我再补充几个实践中的判断依据。工具链方面不用过度迷信某个特定版本。我建议先用 Ubuntu 自带的交叉工具链快速跑通全流程确认代码能编译、板子能运行再回头考虑是不是要换 Linaro 或其他定制工具链。先用最简单的方案验证比一开始就纠结工具链版本要高效得多。依赖库版本方面zlib 选 1.2.12 或 1.2.13 都可以OpenSSL 尽量用 1.1.1 系列的最新小版本。版本太老会有安全告警版本太新和 librtmp 的 API 兼容性又容易出问题1.1.1 是当前最稳妥的选择。至于 librtmp 本身直接拉 rtmpdump 仓库的 master 分支一般没问题这是社区长期维护的活跃仓库比找几个镜像站的老 release 包更可靠。集成方面如果你的项目里还要用 Qt 或者 ffmpeg思路是一样的先保证这三个库的交叉编译产物齐全再向外扩展。librtmp 只是整个链路的一环把依赖和工具链理清楚后面编什么都顺。最后再分享一个我特别推荐的检查习惯编译完不管是什么架构的库和程序都先用file和readelf确认当前架构和依赖拷贝到板子之前就排查掉一半的问题。等上了板子再排查调试成本高出好几倍不说还容易让人怀疑是硬件或系统层面的问题白白浪费时间。本文还有配套的精品资源点击获取
