跳到主要内容

SDK 编译问题定位

在编译 SDK 的时候会遇到许多问题，本篇文档将几处常见的错误列出来以供排除定位参考。

编译软件包失败​

image-20241126125730263

部分软件包会编译失败，此时会输出 More error defails please refer to: 此时可以打开查看这个文件，看一下是因为什么导致的问题，在这里命令如下：

cat /home/ubuntu2404/tina-v821/openwrt/openwrt/build_log/tools/cmake//compile.txt

可以看到问题原因read jobs pipe: Resource temporarily unavailable. Stop，是因为虚拟机配置的性能较低，编译不过来了，此时增加虚拟机配置即可。

image-20241126125926655

打包报错 ERROR: update_mbr failed​

image-20241122162931588

查看日志可以看到 ERROR: dl file amp_rv0.fex size too large 说明分区表分配的大小不足以塞下固件，需要修改固件大小，还可以看出是 riscv0 这个分区的大小不够。又因为是NOR方案，所以修改对应板级的 sys_partition_nor.fex，将分区大小修改到固件的对应大小，注意要对齐128扇区。这里需要2413扇区，对齐后是2432扇区

image-20241122163452631

再次打包便正常打包完成了

image-20241122163518616

打包出现报错 cannot execute: required file not found​

image-20241126133059699

系统需要安装 i386 架构支持，WSL1 需要切换到WSL2上开发，WSL1不支持 multilib 

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt install gcc-multilib 
sudo apt install libc6:i386 libstdc++6:i386 lib32z1

WSL 编译出现编译器错误​

image-20250211130228969

工具链的 glibc 实现时会用到 vsyscall，而WSL2默认禁用 vsyscall

在Linux环境中，vsyscall（虚拟系统调用）是一种用于提高系统调用性能的机制，尤其是在调用频繁的小型系统调用时。它通过直接从用户空间访问内核代码来减少上下文切换的开销。vsyscall提供了一个快速的方式来执行一些系统调用，例如 gettimeofday()、time()、mmap() 等。

然而，在一些现代的Linux系统中，尤其是在WSL2（Windows Subsystem for Linux 2）中，默认禁用了 vsyscall。WSL2的虚拟化技术使得它与常规的Linux内核有所不同，WSL2采用了Hyper-V虚拟机来运行Linux内核，因此可能会采取不同的策略来优化性能。

WSL2 还需要进一步配置：

  • 打开 vsyscall 支持

打开 %userprofile% 目录。

image-20250113143954401

新增文件 .wslconfig

image-20250113144034272

打开 .wslconfig 并添加以下內容

[wsl2]
kernelCommandLine = vsyscall=emulate # Additional kernel command line arguments

.wslconfig 相关参考：wsl-config

修改完成后请重启 WSL 环境

wsl --shutdown

然后在新打开的 WSL2 中查看

cat /proc/cmdline

如果输出包含了 vsyscall=emulate ，则说明配置正确，如果没有显示这两个选项，则可能配置错误，请参考：wsl-config 进行排查

  • vsyscall=emulate：启用模拟 vsyscall。

WSL2 编译出现错误​

由于 WSL2 会默认继承 Windows 的环境变量，而 Windows 的环境变量是包含空格的，这会引起编译失败，需要在使用前清除空格。

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib