[PATCH v2] kbuild: Avoid including architecture-specific Makefile twice

[Michal Simek]

On 7/11/25 16:32, Tom Rini wrote:
> On Fri, Jul 11, 2025 at 08:52:34AM +0000, Yao Zi 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. For
>> config targets, bumping Kbuild also introduced a new include to
>> arch/$(SRCARCH)/Makefile, which is removed as well for consistency.
>>
>> Fixes: 5f520875bdf ("kbuild: Bump the build system to 5.1")
>> Signed-off-by: Yao Zi <ziyao at disroot.org>
>> Reviewed-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
>> ---
>>
>> Changes from v1
>> - Don't describe the problem as RISC-V-specific since it may affect ARM
>>    builds as well.
>> - Prevent config targets from including for architecture-specific
>>    Makefile as well for consistency.
>> - Add comments to explain the removal.
>> - Link to v1: https://lore.kernel.org/u-boot/20250709161418.21287-2-ziyao@disroot.org/
>>
>>   Makefile | 11 +++++++----
>>   1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index da53efa09f1..e745cc618ba 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -635,8 +635,9 @@ ifeq ($(config-targets),1)
>>   # Read arch specific Makefile to set KBUILD_DEFCONFIG as needed.
>>   # KBUILD_DEFCONFIG may point out an alternative default configuration
>>   # used for 'make defconfig'
>> -# Modified for U-Boot
>> --include arch/$(SRCARCH)/Makefile
>> +# Modified for U-Boot: we don't include arch/$(SRCARCH)/Makefile for config
>> +# targets, which is useless since U-Boot has no architecture defining its own
>> +# KBUILD_{DEF,K}CONFIG, or CROSS_COMPILE.
>>   export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
>>   
>>   config: scripts_basic outputmakefile FORCE
>> @@ -724,8 +725,10 @@ endif
>>   ARCH_CPPFLAGS :=
>>   ARCH_AFLAGS :=
>>   ARCH_CFLAGS :=
>> -# Modified for U-Boot
>> --include arch/$(SRCARCH)/Makefile
>> +# Modified for U-Boot: we put off the include of arch/$(SRCARCH)/Makefile until
>> +# making sure include/config/auto.conf is up-to-date and include of config.mk,
>> +# because the architecture-specific Makefile may make use of variables defined
>> +# in config.mk. See also the comment about autoconf_is_old.
>>   
>>   ifeq ($(dot-config),1)
>>   ifeq ($(may-sync-config),1)
> 
> Since Fabio confirmed this fixes his issue, I'd like one or two more
> tested-by's if I can before the end of the day when I'll apply this.
> Thanks!
> 

Tested-by: Michal Simek <michal.simek at amd.com>

Thanks,
Michal