在Ubuntu 20.04上搞定创龙T113 SDK编译：我踩过的那些Python和gdbus的坑
在Ubuntu 20.04上搞定创龙T113 SDK编译：我踩过的那些Python和gdbus的坑
嵌入式开发总是充满惊喜——尤其是当你决定不走寻常路，在非官方推荐环境下折腾SDK编译时。作为一款性价比突出的国产处理器，全志T113在创龙开发板上展现出的潜力吸引了不少开发者。但当你兴冲冲地在Ubuntu 20.04上展开工作时，很快就会发现官方手册里没写的那些"隐藏关卡"正等着你。本文将带你直击三个最具代表性的编译陷阱：Python版本的地雷阵、gdbus的null指针谜题，以及awk脚本的语法暗礁。
1. 环境准备：当现代Linux遇上传统工具链
创龙官方推荐使用定制化Ubuntu镜像，但很多开发者更习惯在标准LTS系统上工作。我的Ubuntu 20.04初始环境就遇到了第一个下马威——Python版本冲突。现代Linux发行版普遍将python命令指向Python 3，而老牌嵌入式SDK往往固执地需要Python 2。
诊断过程：
$ python --version Command 'python' not found... $ ls -l /usr/bin/python* lrwxrwxrwx 1 root root 9 Apr 5 2020 /usr/bin/python3 -> python3.8解决方案看似简单，实则暗藏玄机：
sudo rm -f /usr/bin/python # 清除已有链接 sudo ln -s /usr/bin/python2 /usr/bin/python但要注意，这会影响系统级Python脚本。更稳妥的做法是修改SDK中的脚本，显式调用python2。我在build.sh中发现了几处硬编码的python调用，将其改为python2后既解决了问题，又避免污染系统环境。
2. gdbus编译错误：当安全检查遇上激进优化
进入编译阶段后，gdbus相关错误突然杀出：
gdbusauth.c:1302:11: error: ‘%s’ directive argument is null gdbusmessage.c:2702:30: error: ‘%s’ directive argument is null这些错误源于Glibc 2.34引入的格式字符串安全检查。现代编译器会对printf类函数进行严格检查，而SDK中的老代码未能通过这项检测。
修复方案对比：
| 修改方式 | 优点 | 风险 |
|---|---|---|
| 添加NULL检查 | 代码健壮性高 | 需要修改多处 |
| 禁用警告 | 改动量小 | 掩盖潜在问题 |
| 替换格式说明符 | 兼容性好 | 可能影响日志格式 |
我选择了最彻底的方案——在gdbusauth.c第1302行和gdbusmessage.c第2702行添加NULL检查：
// 修改前 g_debug("Auth response: %s", response); // 修改后 if (response) { g_debug("Auth response: %s", response); } else { g_debug("Auth response: (null)"); }3. awk脚本陷阱：正则表达式的方言战争
当你以为胜利在望时，buildroot阶段又抛出神秘错误：
`\#' is not a known regexp operator这个问题源于不同awk实现的正则表达式方言差异。GNU awk(gawk)能识别\#转义，但更严格的实现会报错。
受影响的脚本文件：
- mkerrnos.awk
- mkerrcodes.awk
- mkerrcodes1.awk
- mkerrcodes2.awk
- mkstrtable.awk
统一修改方案是将所有sub(/\#.+/, "");替换为：
sub(/#.+/, ""); # 移除转义反斜杠4. 幽灵文件之谜：自动生成机制的失效
最棘手的错误出现在最后阶段——系统提示errnos-sym.h文件为空或不存在。这个本应由脚本自动生成的文件竟然缺席了。
解决步骤：
- 在CSDN上找到相似案例的解决方案
- 手动创建
errnos-sym.h文件 - 将其放置到指定目录：
/home/[user]/T113/T113-i_v1.0/out/t113_i/tlt113-minievm-emmc/longan/buildroot/build/libgpg-error-1.33/src关键点在于理解这个文件的用途——它是libgpg-error的一部分，包含错误码到字符串的映射关系。虽然手动解决方案可行，但更好的做法是修复自动生成机制：
# 进入buildroot目录 cd buildroot # 清理并重新生成 make clean && make经过这四轮攻防战，最终在标准Ubuntu 20.04上成功完成了T113 SDK的完整编译。整个过程教会我的不仅是具体问题的解决方法，更重要的是嵌入式开发中的排查思路：从错误信息出发，结合系统差异分析，最后选择对系统影响最小的解决方案。下次当你遇到类似的"非官方环境"挑战时，不妨记住这三个原则：版本兼容性检查、编译器行为差异、自动化流程验证。