使用GCC 9.3.0为Ubuntu 20.04编译Linux Kernel时dpkg-buildpackage报错

当前展示的报错属于make调用链的上层错误栈，并非根因信息，真实的编译错误一定出现在该段日志之前的编译输出内容中，优先向上翻找日志定位具体错误。常见触发该类报错的原因如下：

• 编译依赖缺失：Ubuntu内核编译所需依赖未安装完整，常见缺失依赖包含build-essential、libncurses-dev、bison、flex、libssl-dev、libelf-dev、dpkg-dev、debhelper、fakeroot，任意依赖缺失都会在编译对应模块时报错，触发上层错误栈。
• 内核配置冲突：若自行修改过内核.config配置文件，开启了不存在的硬件驱动、配置项逻辑冲突、或选中了与当前架构不兼容的选项，都会导致编译中断。如果是基于当前系统配置修改的内核配置，可先执行make olddefconfig自动补全兼容默认值，规避配置项遗漏问题。
• 系统资源不足：使用全部CPU核心并行编译时内存占用较高，若系统内存小于4G且未配置交换空间，编译进程易被系统OOM机制终止，该场景下错误日志前段会存在Killed signal terminated program cc1类提示。可通过降低并行编译核心数（例如将命令调整为make -j2 deb-pkg LOCALVERSION=-custom）、新增交换空间解决。
• 源码完整性问题：若使用的内核源码为未正式发布的测试分支、下载过程中文件损坏、或源码被改动引入逻辑错误，也会触发编译失败。建议确认源码完整性，或切换到稳定LTS分支编译。
• 编译器版本不兼容：若编译的是6.0及以上版本的Linux内核，GCC 9.3.0版本无法满足编译要求，高版本内核要求GCC 11及以上版本，该场景下日志前段会明确提示编译器版本不兼容错误。

排查建议 #

可将编译输出重定向到日志文件便于后续检索错误，参考命令：

make -j $(getconf _NPROCESSORS_ONLN) deb-pkg LOCALVERSION=-custom 2>&1 | tee build.log

报错后直接检索日志文件内的error:关键词即可快速定位根因。

内容的提问来源于stack exchange，提问作者Some Name