为何在Debian 13(WSL2)编译Rockchip SDK内核不沿用Ubuntu 18.04？

前言 Rockchip（瑞芯微）官方的 SDK（如 RV1126 或 RK3588）通常推荐使用 Ubuntu 18.04 作为编译环境。然而，在 2025 年的今天，死守着一个早已停止维护的老旧发行版既不安全也不方便。 笔者更偏爱使用 Debian 13 (Trixie/Sid) 配合 WSL2 (Windows Subsystem for Linux) 进行开发（当然可能是懒得再装一个）。这不仅能享受到最新的软件包和工具链，还能无缝集成 Windows 的生产力工具。 但强行使用新环境编译老 SDK，注定是一条充满荆棘的路。除了常规的依赖缺失（如 Python 版本问题），最让人头疼的是WSL2 环境变量污染以及新版 GCC 编译器对语法检查的严格化。 本文将跳过基础依赖安装（如 python-is-python3 软链等常规操作），重点梳理并解决在 Debian 13 (WSL2) 下编译内核时遇到的三个“硬骨头”。 痛点一：WSL2 环境变量“污染”导致编译失败 在 WSL2 中，为了方便互操作，Windows 会自动将其系统 PATH 追加到 Linux 的 PATH 中。这导致编译脚本可能会错误地调用 Windows 下的工具（如某些 .exe 程序或者名字冲突的工具），从而引发莫名其妙的报错。 我们需要构建一个绝对纯净的 Linux 编译环境。 解决方案：创建环境清洗脚本 不要直接运行 ./build.sh，而是创建一个名为 clean_build.sh 的封装脚本，强制重置 PATH。 新建脚本 clean_build.sh： Bash #!/bin/bash # 设置一个干净的、仅包含 Linux/WSL 系统基本路径的 PATH export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin echo "=================================================" echo "Using a sanitized PATH for the build process:" echo "$PATH" echo "=================================================" # 执行原始的编译脚本 ./build.sh 使用方法： Bash chmod +x clean_build.sh ./clean_build.sh 痛点二：GCC 升级导致的“隐式声明”报错 Debian 13 搭载了较新的 GCC 版本（GCC 12/13+）。新标准默认将 C99 中的 implicit-function-declaration（函数隐式声明）视为 Error 而不仅仅是 Warning。Rockchip SDK 中引用的部分旧开源库（如 libffi 和 zip）代码风格较老，在新编译器下会直接炸裂。 我们需要通过补丁来修复这些源码。 问题 A：libffi 中的函数未声明 在编译 host-libffi 或相关组件时，会报错提示 open_temp_exec_file 未声明。这是因为该函数在 tramp.c 中被调用，却未在该文件中引用头文件或声明。 解决方案：应用补丁 0003-fix-implicit-declaration-of-open_temp_exec_file.patch 请保存以下内容为 .patch 文件并应用： C --- a/src/tramp.c +++ b/src/tramp.c @@ -69,6 +69,9 @@ void __attribute__((weak)) *ffi_tramp_arch (size_t *tramp_size, void __attribute__((weak)) *ffi_tramp_arch (size_t *tramp_size, size_t *map_size); +/* Declare function from closures.c to avoid implicit declaration */ +extern int open_temp_exec_file (void); + /* ------------------------- Trampoline Data Structures --------------------*/ struct tramp; 问题 B：zip 配置脚本中的 memset 检测失败 这是最隐蔽的一个坑。