1. 为什么绕这么大一圈WSL 交叉编译 deb 的完整链路1.1 先想清楚产物形态Windows 上为什么需要 deb最近我在折腾一块基于 RK3568 的开发板板子系统是 Debian 系的 ARM64 版本。需求很朴素我需要在板子上跑一个自己写的网络抓包小工具带一个配置文件和一个 systemd 服务。开发机是 Windows 笔记本平时写代码、跑测试都在上面板子只是偶尔连一下。如果直接把源码丢到板子上现场编译也不是不行但板子性能摆在那里编一个稍大的项目动辄几分钟到十几分钟而且还要在板子上装一堆 build-essential 依赖把运行环境搞得乱七八糟。更麻烦的是每次改几行代码就要重新上板编译一轮调试节奏被拖得很难受。所以最合理的方案是在 Windows 上的 WSL 环境里做交叉编译直接把产物打包成一个 arm64 的 .deb 文件传到板子上执行一行sudo dpkg -i装好。这样做的好处非常明显第一编译不占板子资源第二deb 包自带文件清单、依赖声明和卸载逻辑后续想去掉某个软件只需要dpkg -r不会在系统里留下零散文件第三整个流程可以写成脚本固化下来哪怕换一台电脑几分钟就能把打包环境重新搭起来。这篇内容就是完整记录我这一趟从零到一的实操过程包括 WSL 环境准备、交叉编译工具链安装、deb 包结构拆解、打包命令细节以及最后上板安装时遇到的一堆坑。适合正在做 ARM 板端开发、想把 Windows 变成交叉编译工作站的读者参考。1.2 交叉编译的选型思路为什么不用板子上的原生编译很多人第一次接触交叉编译时会觉得麻烦明明有板子直接在上面编译不就行了实际用过就会发现原生编译在小板子上是不得已的选择而不是优选方案。RK3568 这类板子CPU 性能放在桌面级处理器面前还是差着量级编译一个依赖较多的 C 项目板子上可能要 3 到 5 分钟PC 上配合交叉编译十几秒就出结果。更关键的是频繁在板子上安装编译工具链、头文件包会让系统环境变得不可控今天缺一个依赖装一个明天又发现版本冲突最后板子系统被搞得很脏你根本分不清哪些包是运行需要的、哪些只是编译需要的。交叉编译的本质就是在一台性能强的机器上用目标架构的编译器生成目标架构的机器码。一台 x86_64 的电脑通过aarch64-linux-gnu-gcc编译出来的二进制可以直接在 arm64 Linux 上跑前提是运行时库版本匹配。它跟原生编译最大的区别在于编译时的链接路径、头文件路径、动态库搜索路径都指向目标系统的 sysroot而不是本机路径。这一点恰恰是很多人第一次交叉编译踩坑的重灾区后面我会专门讲。在 Windows 上做交叉编译理论上也有原生方案比如直接装 MSYS2 或者用 ARM 的编译器在 Windows 下交叉编译 Linux 目标但如果你需要的是 Linux 环境下的 deb 包那最稳妥的宿主环境本身就是 Linux。WSL 恰好提供了这个条件你不需要装双系统不需要开虚拟机在 Windows 上直接开一个 Ubuntu 子系统就能获得完整的 Linux 文件系统和工具链支持。1.3 工具链怎么选系统包与板厂 SDK 的取舍交叉编译工具链的选择我实测下来有两条路。第一条是从 Ubuntu 官方源直接安装命令是sudo apt update sudo apt install gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu这条路径的好处是省事系统自动把编译器、汇编器、链接器都装好工具链前缀是aarch64-linux-gnu-。对大多数自己写的小工具、依赖少的项目来说完全够用。第二条路是用板厂 SDK 自带的交叉编译工具链比如 RK3568 开发板配套的 SDK 里一般都会有完整的交叉编译环境包含对应的 sysroot、板子上的运行库版本和头文件。我建议如果你的项目要链接板子上特定的第三方库而且这些库在 Ubuntu 默认源里没有对应 arm64 版本那就老老实实用板厂 SDK 的工具链因为它带了一套跟你板子系统匹配的 sysroot编译出来的程序直接能找到运行库。如果只是编一个依赖少的独立程序比如纯 C 写的命令行工具、静态链接的处理程序直接用gcc-aarch64-linux-gnu就够了省去下载 SDK 的几个 GB 体积。我这次属于前者因为程序要链接板子上已有的一个私有库所以我下载了板厂提供的工具链解压后直接加到 PATH 里用。这里有个很重要的细节工具链版本与板子系统运行库版本之间是有匹配关系的。你说不清哪天就会遇到“编译时好好的一上板就告诉你缺少某个 libc.so.6 版本”的问题这通常就是工具链太新、而板子系统运行库太旧导致的。稳妥的办法是编译完成后在 WSL 里用readelf -V看一下程序依赖的 GLIBC 版本跟板子上的比对一下。2. 环境准备WSL 搭建与交叉编译工具链安装2.1 WSL 环境安装与基本配置WSL 的安装现在已经很傻瓜化了Windows 10 以上版本管理员权限打开 PowerShell执行wsl --install默认会装最新版的 WSL2并为你安装一个 Ubuntu 发行版。如果你的网络环境不太稳定wsl --install一直失败可以加--web-download参数让安装源走 Web 下载而不是 Microsoft Storewsl --install --web-download这个参数是我在很多次安装失败的现场总结出来的救命选项。新装的 WSL 默认会把发行版放在 C 盘如果你 C 盘空间吃紧建议把发行版安装到其他盘。可以先装好之后再导出迁移wsl --export Ubuntu D:\wsl\ubuntu-backup.tar wsl --unregister Ubuntu wsl --import Ubuntu D:\wsl\ubuntu D:\wsl\ubuntu-backup.tarwsl --import之后那个发行版默认以 root 用户登录需要用/etc/wsl.conf配置默认用户或者直接继续用 root 也无妨反正是开发环境。我见过不少人在这一步卡住——“为什么导入后要我输入密码但我没设过密码”就是因为 import 的发行版默认是不带用户的直接一个 root shell。经验之谈WSL 里做交叉编译时尽量把工程代码放在 WSL 内部的文件系统里比如~/workspace。不要放在/mnt/c/这种通过 9P 协议挂载的 Windows 目录下。原因很简单跨文件系统读写的 IO 性能差很多而且编译过程中大量的小文件 create/open 操作在 9P 挂载点上会异常缓慢。我实测过同样的工程放在 WSL 内编译大概 20 秒放在/mnt/c下要一分多钟差距非常明显。2.2 安装 aarch64 交叉编译工具链两条路径实测如果你走系统源路线安装命令如下sudo apt update sudo apt install -y gcc-aarch64-linux-gnu g-aarch64-linux-gnu装完验证一下aarch64-linux-gnu-gcc --version正常会显示版本号。这里需要说明的是Ubuntu 源里的gcc-aarch64-linux-gnu是一个完整的工具链集合包含了aarch64-linux-gnu-gcc、aarch64-linux-gnu-g、aarch64-linux-gnu-ld、aarch64-linux-gnu-ar等命令基本上编译 C/C 项目所需的东西都齐了。但它默认不带一套独立的 sysroot——它编译时使用的头文件和库是借助于交叉编译模式下的 multiarch 路径来定位的对简单项目没问题遇到要找私有库的场景就会抓瞎。板厂 SDK 工具链的安装方式每个厂略有不同但大体一致解压一个压缩包把里面的bin目录加入 PATH。比如我用的这个tar -xvf rk3568-toolchain.tar.gz export PATH$PATH:$PWD/rk3568-toolchain/bin解压之后工具链前缀一般也是aarch64-linux-gnu-或者像石头那边习惯用的aarch64-rockchip-linux-gnu-具体看官方说明。这个工具链的优势在于它自带了匹配板子系统版本的 sysroot通常在lib/gcc/aarch64-rockchip-linux-gnu/xx.x.x/下能找到对应的头文件和库目录。用这种工具链编译时链接器和编译器会自动使用内置 sysroot不需要额外配置。两种方案我建议怎么选如果你只是编一个自己在 PC 上写的小工具且它没有特殊的系统依赖用源里装的系统包就够了速度快、不占空间。如果你要复用板子上某个已有的库比如板厂提供的音频处理库、硬件编解码库或者你的目标系统用的是旧版 Ubuntu 而源里的工具链太新就老老实实用 SDK 工具链。你不想在板子上装一堆额外依赖的话这一点很关键。2.3 验证工具链交叉编译 Helloworld工具链装好后先编一个最小程序验证全链路是否通了。在 WSL 里创建一个测试文件mkdir ~/cross-test cd ~/cross-test cat hello.c EOF #include stdio.h int main() { printf(hello arm64\n); return 0; } EOF用工具链编译aarch64-linux-gnu-gcc -o hello hello.c然后看产物架构file hello正常输出里应该有hello: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1看到ARM aarch64就说明编译目标对了。如果输出的是x86-64赶紧检查是不是调用了本机 gcc把命令写错了。这个检查动作看起来基础但我在实际项目里见过有人把CC环境变量指错了编了一天全编成 x86 的最后上板一片“Exec format error”。另外如果你用的是板厂工具链最好也用它的readelf和objdump因为版本匹配解析出来的依赖信息更贴近板子的实际情况。检查动态库依赖可以这样aarch64-linux-gnu-readelf -d hello | grep NEEDED看到libc.so.6、ld-linux-aarch64.so.1这类输出就说明依赖解析正常。3. 从源码到 deb 包工程配置与打包全流程3.1 交叉编译真实项目以 CMake 工程为例验证完 Helloworld接下来用一个真实规模的工程来说明。假设项目叫netmon功能是采集系统网络流量并定时打印统计信息依赖一个板子上已有的私有库libboard_utils.so。工程结构如下netmon/ ├── CMakeLists.txt ├── include/ │ └── netmon.h ├── src/ │ ├── main.c │ └── collect.c └── debian/ └── control在工具链安装好、sysroot 路径确定后CMake 交叉编译的关键是提供一个 toolchain 文件。我习惯在工程根目录放一个cmake/aarch64-toolchain.cmakeset(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(TOOLCHAIN_PREFIX aarch64-linux-gnu) set(CMAKE_C_COMPILER ${TOOLCHAIN_PREFIX}-gcc) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PREFIX}-g) set(CMAKE_FIND_ROOT_PATH /path/to/sysroot) 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)其中CMAKE_FIND_ROOT_PATH指向工具链的 sysroot 目录。如果你用的是 Ubuntu 源装的工具链这个路径通常是/usr/aarch64-linux-gnu如果你用的是板厂 SDK 工具链一般是工具链目录下带sysroot的某个路径。前三行MODE_*的意思分别是查找程序时可以在宿主系统找因为 cmake 需要执行宿主机程序但查找库和头文件时只能在 sysroot 里找防止误取 x86 的库。这个配置如果不写最常见的现象就是 cmake 悄悄找到了宿主机的 x86 库编译时一堆 “skipping incompatible” 报错或者干脆链接出问题。然后 configure 阶段这样执行mkdir build cd build cmake -DCMAKE_TOOLCHAIN_FILE../cmake/aarch64-toolchain.cmake -DCMAKE_INSTALL_PREFIX/usr .. make -j$(nproc)这里CMAKE_INSTALL_PREFIX/usr是给后续打包用的我们希望make install后产物天然是/usr/bin/netmon这样的路径deb 包解包后正好覆盖到系统对应位置。如果你想把二进制放到/usr/local/bin也可以但要注意 deb 包的路径一致否则包管理器追踪文件时会对不上。3.2 编写 DEBIAN/control 元数据deb 包的核心说明书deb 包的构造基于一个我最初很容易忽略、但实际很简单的结构。一个 deb 包本质上是一个 ar 归档里面有三个东西debian-binary版本号声明、control.tar.*包含 control 等元数据文件、data.tar.*包含实际安装的文件。手动构造时官方推荐用dpkg-deb --build它会帮你把这些打包动作做好。你只需要准备一个目录里面是两个子目录DEBIAN/和模拟根目录的内容。比如netmon-pkg/ ├── DEBIAN/ │ └── control ├── usr/ │ ├── bin/ │ │ └── netmon │ └── lib/ │ └── netmon/ │ └── config.ini └── lib/ └── systemd/ └── system/ └── netmon.serviceDEBIAN/control文件是包的核心说明书我习惯写成这样Package: netmon Version: 1.0.0-1 Section: utils Priority: optional Architecture: arm64 Maintainer: Netmon Maintainer netmonexample.com Depends: libc6 ( 2.31), libboard-utils1 Description: Network traffic monitor for embedded ARM Linux A lightweight tool to collect network statistics, designed for ARM64 Linux devices.几个字段必须重点说明Architecture: arm64是最关键的。如果写错成amd64dpkg 会拒绝安装并提示当前机器架构与包不匹配。Depends字段声明了运行依赖如果你不确定私有库的 deb 包名是什么先不写也行但这样安装时不会有依赖提示运行时才发现库不存在就很被动。建议编译阶段用readelf -d看依赖的库名然后对照板子上dpkg -S查一下库属于哪个包再填进去。还有一个可选的conffiles文件也很实用。如果你的程序带配置文件在DEBIAN/conffiles里声明它/etc/netmon/config.ini这样用户以后修改了配置文件升级包的时候 dpkg 会智能地保留原文件而不是直接覆盖。不加这个文件每次升级你的配置文件都会被打回原形对使用者很不友好。3.3 dpkg-deb 打包含命令详解把文件都放好后在netmon-pkg的父目录执行dpkg-deb --build --root-owner-group netmon-pkg netmon_1.0.0-1_arm64.deb--root-owner-group这个参数我第一次打包时不知道导致打出来的包内所有文件的所有者都是当前 WSL 里的用户名安装到板子上以后/usr/bin/netmon这种属于 root 的文件变成了普通用户所有虽然功能没大问题但在系统管理上很别扭。加了这个参数包内所有文件的属主会被强制设置为 root:root这才是 deb 包的标准状态。打包完成后马上用两个命令检查dpkg-deb --info netmon_1.0.0-1_arm64.deb dpkg-deb --contents netmon_1.0.0-1_arm64.deb--info显示 control 内容确认架构和依赖字段--contents列出包内文件确认路径是否完整、有没有多余文件混进来。这一步虽然简单但能在上板前发现 90% 的问题比如误把编译中间文件打进包、路径少了或多了一层目录。我把这个检查步骤固化成了习惯每次打包完先不慌着传板子先花三十秒自检这两个命令的输出。还有一种情况经常遇到打好的包里有 WSL 系统自动生成的usr/bin/netmon之外还混进了类似build/的目录、.git文件等。这是因为有些人直接对整个工程目录执行打包没有用一个干净的 staging 目录。比较规范的做法是在 CMake 里设置DESTDIRmake install DESTDIR$PWD/../netmon-pkg这样 CMake 会把install路径以 staging 目录为根写入既保证路径正确又不会误带无关文件。3.4 包内容合规性“ldd 检查”“file 检查”双保险上板前我习惯做一次双保险检查。第一步看动态库依赖是否完整aarch64-linux-gnu-readelf -d usr/bin/netmon | grep NEEDED如果看到如下依赖0x0000000000000001 (NEEDED) Shared library: [libboard_utils.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]就要先在板子上确认libboard_utils.so.1是否存在。如果它存在于/usr/local/lib但程序找不到那可能是链接时没有设置 RPATH或者程序自带的 RPATH 不包含该路径。此时可以用 patchelf 修改 RPATH或者在交叉编译时通过-Wl,-rpath,/usr/local/lib把搜索路径写死。不过这个优先级要排低一点尽量不要靠 RPATH 解决运行库问题能装到标准路径就装到标准路径。第二步是检查架构file usr/bin/netmon确认输出包含ARM aarch64。这两步检查如果都通过再把编译产物复制到 staging 目录、重新打包基本不会出岔子。4. 上板安装从 Windows 传到开发板的一百种方式4.1 传输方案对比scp、ADB、U盘怎么选deb 包打包完成后问题变成了“怎么把文件弄到板子上”。我列一下实测过的方案以及各自的适用场景传输方式前置条件适用场景坑点scp 走局域网板子和电脑同一网段日常开发无线传输需要配好 IP 和 ssh serverWindows 自带 scp 但语法略不同ADB push板子开启 adb 调试Android/Linux 双系统板子或系统内自带 adb需要在板子上打开 adb 服务U 盘拷贝手头有 USB 存储板子没有网络或调试网口不方便拔插麻烦多步操作串口 zmodem只有串口线救急场景速度极慢几百 KB 都要等很久我日常用得最多的是 scp。在 Windows 的 PowerShell 里可以直接调用 scp但更顺手的方式是在 WSL 里执行cd ~/workspace scp netmon_1.0.0-1_arm64.deb root192.168.1.100:/root/注意 Windows PowerShell 的 scp 和 WSL 里 Ubuntu 的 scp 是两个实现前者偶尔对路径处理有莫名的 bug后者干净利落。另一个实用技巧如果板子的 IP 经常变动可以在 WSL 的/etc/hosts里给它固定一个名字比如rk3568之后所有命令都不需要记 IPscp netmon_1.0.0-1_arm64.deb rootrk3568:/root/4.2 板子上执行 dpkg -i 的完整流程传输完成后SSH 登录到板子ssh rootrk3568然后执行安装cd /root sudo dpkg -i netmon_1.0.0-1_arm64.deb如果一切正常输出会提示正在解包、配置包最后没有报错。这时候程序就已经安装到/usr/bin/netmon配置文件在/etc/netmon/systemd 服务也注册好了。整个软件分发过程变成了一行命令这对后续多台板子部署的意义非常大你不用手动拷贝二进制、创建目录、复制配置文件、写 systemd unit只要一行dpkg -idpkg 帮你把所有事情做完了。我在实际部署里还遇到过一种情况板子上没有 sudo或者当前用户不是 root。这时要用 root 身份执行su -c dpkg -i /root/netmon_1.0.0-1_arm64.deb顺便说一句很多轻度使用的开发板默认 root 登录没有普通用户的概念所以 sudo 反而会报错。提前确认当前用户名和权限比在安装时措手不及要省心。4.3 安装后的验证、查询与卸载安装完成后三个验证命令顺序走一遍which netmon netmon --version systemctl status netmonwhich确认二进制路径、--version确认程序能正常跑起来systemctl status确认 systemd 服务注册成功。如果服务不能启动查看日志和排查就是下一件事。卸载同样简单sudo dpkg -r netmon这个命令会按照 deb 包内的文件清单把程序相关的文件全部移除。对比一下手动部署的卸载——你要记得自己复制过哪些文件、创建过哪些目录、注册过哪个 systemd unit还得手工清理。这就是为什么我强烈建议哪怕只部署一台板子也要走 deb 包路线因为它的安装、升级、卸载生命周期都是有序的你不需要用大脑去维护一份 “我自己手动放了哪些文件” 的清单。5. 常见问题与排查实录5.1 板子上提示 “No such file or directory” 的真相这是交叉编译后上板最常见的报错也是最容易误导人的。一个 arm64 的二进制在 arm64 Linux 上执行理论上不应该出现“找不到文件”的错误但如果你把程序放到板子上执行./netmon报错往往是bash: ./netmon: No such file or directory。原因有两种可能一是程序是动态链接的而它依赖的ld-linux-aarch64.so.1在系统里不存在或版本不匹配二是程序本身链接了不存在的库。注意bash 的报错提示没有细说“缺的是哪个文件”它只会模模糊糊地说“No such file or directory”。排查办法是用板子上的file和lddfile /usr/bin/netmon ldd /usr/bin/netmon如果ldd输出 “not found” 的那一行就是问题所在。比如libboard_utils.so.1 not found说明库没有装到标准路径。解决办法是先检查这个库在板子上的实际位置然后看程序链接时用的搜索路径是否覆盖。如果是静态链接或者只有 libc 依赖那基本是工具链版本太新、生成的二进制要求的 GLIBC 版本比板子系统的高。这就是为什么前面强调工具链与目标系统运行库匹配的重要性。5.2 动态库依赖缺失readelf、ldd 组合排查法在 PC 端提前排查依赖是效率最高的方式不要等上板了才去折腾。PC 端检查工具链的 readelf 命令就能提前看到 NEEDED 列表。但这里要注意交叉编译环境的 readelf 看的是编译时记录的依赖名板子上实际有没有还是得上板验证。所以我在打包前、安装后各做一轮依赖检查打包前用工具链的 readelf 看依赖列表安装后用板子的 ldd 看实际解析结果。两轮检查都通过基本告别“缺库”类问题。还有一种情况比较气人程序跑起来后报version GLIBC_2.34 not found。这意味着二进制链接时要求某个较新的 GLIBC 符号但板子系统里的 GLIBC 比较旧。解决办法首先是尽量让工具链版本贴近板子系统。如果工具链不好换还有一个思路是静态链接-static或是-static-libgcc -static-libstdc这样程序对 GLIBC 的版本要求会降低很多但可执行文件体积会膨胀对嵌入式小系统来说需要权衡。5.3 WSL 安装慢、网络波动怎么处理WSL 首次安装时最容易遇到的问题wsl --install卡在某个进度或者提示安装失败、被重置。我实测下来最有效的几个办法按顺序排列先用 Web 下载方式代替默认 Store 方式wsl --install --web-download还不行就检查 Windows 功能里的虚拟机平台和适用于 Linux 的 Windows 子系统是否都已启用。在管理员 PowerShell 里执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart改完需要重启。如果安装过程中出现“组件存储已损坏”之类的提示说明系统映像不完整先跑sfc /scannow修复系统文件再重试安装。如果你已经有 Ubuntu 的发行包wsl --import方式安装离线发行版也是完全可行的路子我自己用于备份恢复都被这套流程覆盖了。重点提醒WSL 安装慢、失败很多时候跟镜像源质量无关而是网络传输过程中的丢包和超时。与其反复重试在线安装不如把发行版打包成一个 tar 文件备用以后换电脑直接 import。5.4 dpkg 安装报依赖错误解决与规避板子执行dpkg -i时最常遇到的提示dpkg: dependency problems prevent configuration of netmon: netmon depends on libboard-utils1; however: Package libboard-utils1 is not installed.这说明Depends字段里声明的包没有安装。处理办法有两种第一种是先把依赖包装上再用dpkg -i装目标包第二种是强行忽略依赖错误sudo dpkg -i --force-depends netmon_1.0.0-1_arm64.deb但我不推荐为了装包而忽略依赖。缺失的依赖往往意味着程序运行时真的会找不到库。我的做法是在打包的 control 文件里只声明我自己能保证的依赖对于私有库这种没有 deb 化、只存在于板子特定路径的库不声明在 Depends 里而是把它跟主程序一起打进同一个 deb 包或者干脆在安装后脚本里处理。这样既保证了依赖声明不虚假又让安装流程顺畅。另一个常见场景是升级安装sudo dpkg -i netmon_1.1.0-1_arm64.deb如果 control 里的 Version 字段比现有版本低dpkg 会提示版本号不对。这个字段的格式1.0.0-1中最后的-1是 Debian 修订号同一个上游版本号可以有不同的修订号用于修打包层面的问题。升级时只要这个字符串比旧的大就能顺利覆盖。5.5 架构冲突与强行安装的风险还有一种我很早踩过的坑拿 amd64 的包往 arm64 板子上装。dpkg 会立刻拒绝dpkg: error: package architecture (amd64) does not match system (arm64)有些性子急的人会用dpkg --force-architecture -i强制装但这个行为非常危险——x86 的二进制在 ARM 上根本没法执行装上去也是占着一个坏包名额供应链管理会变得乱七八糟。ARM 的板子架构五花八门同样是 arm 系列armhf和arm64就不兼容armel更是另一套世界。检查架构最可靠的方式是看文件名里的_arm64后缀以及 control 文件里的Architecture字段双确认才能放心。补充一个更隐蔽的坑如果你的板子是 32 位用户态但内核是 64 位的光看板子架构很容易混淆。最稳妥的办法是安装前在板子上执行dpkg --print-architecture它会输出当前用户态架构比如arm64或armhf。以这个输出为准不要自己猜。6. 最后的实操心得几轮折腾下来我个人最大的体会是把“在 Windows 上打包 arm64 的 deb”这件事做好核心不在某一条命令上而在于形成一套环环相扣的流程。从 WSL 环境的搭建、工具链与目标系统的匹配、CMake 交叉编译的 sysroot 配置到 staging 目录的构建、control 文件的字段语义再到上板安装后的依赖验证每一步的失误都会在最后暴露成奇怪的运行时错误。我在实际项目里形成的习惯是每次打完包先花一分钟检查架构和依赖再花一分钟确认 control 字段最后才传板子。这个小习惯帮我省下的调试时间远比一分钟的检查成本多得多。如果你后续打算把多个板子纳入统一管理这套流程还可以继续扩展。比如把 deb 包放到局域网内的一个简单 HTTP 目录板子上配置 apt 源指向它然后一行apt update apt install netmon就能批量部署也可以写一个 GitHub Actions 或 Jenkins 流水线把 WSL 里的打包步骤云化代码一推送自动产出 deb。这些都是在打好一个包之后自然生长出来的能力。对着你的板子折腾一遍你会发现自己对 Linux 包管理、交叉编译和嵌入式部署的理解都会再上一个台阶。
