RISC-V平台编译OpenKylin2.0内核6.6时__efistub_efi_zboot_entry未定义引用问题的技术问询

咱们一步步拆解你遇到的问题——你已经摸到了核心原因，接下来结合上游内核的设计逻辑给你梳理清楚：

核心问题到底出在哪？ #

你观察的完全没错：__efistub_efi_zboot_entry是zboot.c里的efi_zboot_entry通过objcopy添加前缀生成的符号，而这个符号只有在CONFIG_EFI_ZBOOT=y时才会被编译进lib.a。但问题的关键在于：当CONFIG_EFI_ZBOOT=n时，zboot-header.o仍然被编译并参与了vmlinuz.efi的链接流程，这就直接导致了未定义引用的错误。

为什么上游Debian/Ubuntu内核不会踩这个坑？ #

上游内核的构建逻辑里，zboot-header.o的编译是和CONFIG_EFI_ZBOOT强绑定的——只有当这个配置项开启时，才会把zboot-header.S加入编译列表。你遇到的问题，大概率是OpenKylin的自定义内核配置或构建脚本中，误把zboot-header.o的编译规则从CONFIG_EFI_ZBOOT的依赖中解绑了，导致即使关闭该配置，这个目标文件还是被生成并塞进了链接流程里。

符合上游思路的修复方案 #

按照上游内核的设计逻辑，你有两个靠谱的修复方向：

1. 给zboot-header.o加上配置依赖约束 #

找到定义zboot-header.o编译规则的Makefile（大概率在arch/riscv/boot/Makefile或者drivers/firmware/efi/libstub/Makefile.zboot里），把它的编译条件加上CONFIG_EFI_ZBOOT的判断，类似这样：

obj-$(CONFIG_EFI_ZBOOT) += zboot-header.o

这样当CONFIG_EFI_ZBOOT=n时，zboot-header.o根本不会被编译，自然也就不会出现未定义引用的问题。

2. 对齐内核配置与EFI boot需求 #

如果你的目标是构建支持EFI zboot的内核，那应该确保CONFIG_EFI_ZBOOT=y，同时相关的依赖配置（比如CONFIG_EFI_STUB=y）也正确开启。这种情况下，zboot.c会被正常编译，__efistub_efi_zboot_entry符号会被正确生成，链接错误也就自动消失了。

关于“是否是BUG”的结论 #

从上游内核的设计逻辑来看，这确实是一个构建逻辑上的BUG——当某个组件的代码依赖另一个组件的符号时，构建系统必须保证两者的编译状态同步。上游已经通过配置依赖避免了这个问题，所以你的场景里，问题出在自定义发行版对构建脚本或配置规则的修改上。

内容的提问来源于stack exchange，提问作者Mr.D