前言
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 检测失败
这是最隐蔽的一个坑。在编译 zip 工具时，unix/configure 脚本会尝试检测 memset 函数。但老旧的检测代码没有包含 <string.h>。
在新编译器下，这种不包含头文件的 memset 调用会直接编译失败。导致 configure 误判系统不支持 memset，进而启用了一套名为 ZMEM 的后备实现。结果就是：ZMEM 的实现与 glibc 的原生符号冲突，链接时报错。
解决方案：应用补丁 0009-unix-configure-fix-memset-check.patch
我们需要修复 configure 脚本的检测逻辑，显式引入头文件。
Diff
From 74c3e7a5c8b57f04f5a4c9af8b1c3b243421be58 Mon Sep 17 00:00:00 2001
From: xywml <xywml@outlook.com>
Date: Fri, 21 Nov 2025 17:40:00 +0800
Subject: [PATCH] zip: ensure memset check includes <string.h>
When building on modern toolchains, the unix/configure script tests for
`memset` without including `<string.h>`. Since implicit function
declarations are not permitted in C99 and later, this check fails and
the build erroneously enables the ZMEM fallback implementations, which
then conflict with the libc prototypes.
Include `<string.h>` in the test source so the detection works and the
fallback code remains disabled on systems that already provide these
functions.
Signed-off-by: xywml <xywml@outlook.com>
---
unix/configure | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/unix/configure b/unix/configure
index e33168e..df86f21 100755
--- a/unix/configure
+++ b/unix/configure
@@ -329,7 +329,10 @@ do
done
-echo Check for memset
-echo "int main(){ char k; memset(&k,0,0); return 0; }" > conftest.c
+echo Check for memset
+cat > conftest.c << _EOF_
+#include <string.h>
+int main(void){ char k; memset(&k,0,0); return 0; }
+_EOF_
$CC -o conftest conftest.c >/dev/null 2>/dev/null
[ $? -ne 0 ] && CFLAGS="${CFLAGS} -DZMEM"
--
2.47.0重要注意事项
-
换行符格式 ：在保存上述补丁文件时，请务必确保文件使用 Linux 格式换行符 (LF) ，严禁使用 Windows 的 CRLF，否则
patch命令会报错或无法正确识别。 -
应用时机：这些补丁通常需要在 SDK 解压源码后、开始编译配置前打入对应的源码目录。
总结
通过清洗 PATH 和修补因编译器升级导致的语法错误，我们成功在 Debian 13 这种现代 Linux 发行版上跑通了老旧的嵌入式编译流程。希望这篇排坑记录能帮到同样不想装 Ubuntu 18.04 的开发者们。