Hi Yao,
On Wed, 9 Jul 2025 at 19:15, Yao Zi <[email protected]> wrote: > > Stranges errors are observed when building U-Boot master for almost any > RISC-V board, the messages are in two types, one is about duplicated > symbols, > > u-boot/arch/riscv/cpu//mtrap.S:32: multiple definition of > `trap_entry'; > arch/riscv/cpu/mtrap.o: u-boot/arch/riscv/cpu//mtrap.S:32: first > defined here > > and the other is fixdep's complaint about missing dependency files, > > fixdep: error opening file: arch/riscv/cpu/.mtrap.o.d: No such file > or directory > fixdep: error opening file: arch/riscv/cpu//.start.o.d: No such file > or directory > > where the latter could only be reproduced when building parallelly. > > Both the two types of errors are about files in arch/riscv/cpu, and > there's a suspicious slash character in the reported path. Looking > through RISC-V-specific Makefiles, there's only one place that may > expand to such a path, > > libs-y += arch/riscv/cpu/$(CPU)/ > > The right hand expands to "arch/riscv/cpu//" if $(CPU) isn't defined at > the time of including. With some debug statement added to > arch/riscv/Makefile, the output proves that arch/riscv/Makefile is > included twice, once with $(CPU) undefined and once defined correctly > according to CONFIG_SYS_CPU. > > Futher bisecting shows an extra include statement against > arch/$(SRCARCH)/Makefile is added in earlier bump of Kbuild system. But > the statement is evaluated before config.mk is included and definition > of $(CPU), causing objects in arch/riscv/cpu/ are built and linked twice > (once as "arch/riscv/cpu/*", and once as "arch/riscv/cpu//*"), resulting > in the error. > > Let's simply remove the extra include to fix these nasty errors. Note > though this therotically affects all architectures, ones except RISC-V > may not reproduce similar errors since there are no source files > directly under arch/*/cpu, thus the extra include doesn't hurt. There's another unconditional include under ifeq ($(config-targets),1). Should we remove that as well? The patch it self seems correct, but can you try removing the pre-existing include instead and add the config.mk inclusion? Something like diff --git a/Makefile b/Makefile index db8d89587290..e6ad9be262ef 100644 --- a/Makefile +++ b/Makefile @@ -636,6 +636,7 @@ ifeq ($(config-targets),1) # KBUILD_DEFCONFIG may point out an alternative default configuration # used for 'make defconfig' # Modified for U-Boot +include config.mk -include arch/$(SRCARCH)/Makefile export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT @@ -725,6 +726,7 @@ ARCH_CPPFLAGS := ARCH_AFLAGS := ARCH_CFLAGS := # Modified for U-Boot +include config.mk -include arch/$(SRCARCH)/Makefile ifeq ($(dot-config),1) @@ -773,10 +775,6 @@ ifneq ($(wildcard $(KCONFIG_CONFIG)),) ifneq ($(wildcard include/config/auto.conf),) autoconf_is_old := $(shell find . -path ./$(KCONFIG_CONFIG) -newer \ include/config/auto.conf) -ifeq ($(autoconf_is_old),) -include config.mk -include arch/$(ARCH)/Makefile -endif endif endif I prefer keeping the makefile closer to the kernel so we can sync it up easier in the future Thanks for looking at this /Ilias > > Fixes: 5f520875bdf ("kbuild: Bump the build system to 5.1") > Signed-off-by: Yao Zi <[email protected]> > --- > > I was surprised to see this morning's CI passed[1] even for these RISC-V > boards. Builds for SiFive unleashed, QEMU S-Mode virt and Sipeed Lichee > Pi 4A always fail on my machine with the latest master branch, thus > maybe I missed some points when digging the issue, please correct me if > so. > > [1]: > https://source.denx.de/u-boot/u-boot/-/commit/3833600dbaa2d7008063f3127abf21be8f0fe6cd/pipelines?ref=master > > Makefile | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/Makefile b/Makefile > index da53efa09f1..b610dcc0b6e 100644 > --- a/Makefile > +++ b/Makefile > @@ -724,8 +724,6 @@ endif > ARCH_CPPFLAGS := > ARCH_AFLAGS := > ARCH_CFLAGS := > -# Modified for U-Boot > --include arch/$(SRCARCH)/Makefile > > ifeq ($(dot-config),1) > ifeq ($(may-sync-config),1) > -- > 2.50.0 >
