On Thu, Jul 31, 2025 at 02:52:14PM +0300, Mikko Rapeli wrote: > Hi, > > On Mon, Jul 28, 2025 at 03:43:49PM -0600, Tom Rini wrote: > > On Fri, Jul 18, 2025 at 11:29:58AM +0300, Mikko Rapeli wrote: > > > > > When PLATFORM_LIBGCC was added to linker command it was not > > > added to the dependency of the .so and other rules. Thus a build can > > > try to link *_efi.so files before lib.a from PLATFORM_LIBGCC is available. > > > This was seen in yocto autobuilder builds with u-boot 2025.07 > > > update, see > > > https://lists.openembedded.org/g/openembedded-core/message/220004 > > > > > > https://autobuilder.yoctoproject.org/valkyrie/api/v2/logs/2914600/raw_inline > > > > > > | rm -f lib/efi_loader/built-in.o; arm-poky-linux-gnueabi-ar cDPrsT > > > lib/efi_loader/built-in.o lib/efi_loader/efi_bootmgr.o > > > lib/efi_loader/efi_bootbin.o lib/efi_loader/efi_boottime.o > > > lib/efi_loader/efi_helper.o lib/efi_loader/efi_console.o > > > lib/efi_loader/efi_device_path.o lib/efi_loader/efi_device_path_to_text.o > > > lib/efi_loader/efi_device_path_utilities.o lib/efi_loader/efi_dt_fixup.o > > > lib/efi_loader/efi_fdt.o lib/efi_loader/efi_file.o > > > lib/efi_loader/efi_hii.o lib/efi_loader/efi_hii_config.o > > > lib/efi_loader/efi_image_loader.o lib/efi_loader/efi_load_options.o > > > lib/efi_loader/efi_memory.o lib/efi_loader/efi_root_node.o > > > lib/efi_loader/efi_runtime.o lib/efi_loader/efi_setup.o > > > lib/efi_loader/efi_string.o lib/efi_loader/efi_unicode_collation.o > > > lib/efi_loader/efi_var_common.o lib/efi_loader/efi_var_mem.o > > > lib/efi_loader/efi_variable.o lib/efi_loader/efi_var_file.o > > > lib/efi_loader/efi_watchdog.o lib/efi_loader/efi_disk.o > > > lib/efi_loader/efi_net.o lib/efi_loader/efi_smbios.o > > > lib/efi_loader/efi_load_initrd.o lib/efi_loader/efi_conformance.o > > > | arm-poky-linux-gnueabi-ld.bfd -nostdlib -zexecstack -znocombreloc > > > -znorelro --no-warn-rwx-segments -L > > > /srv/pokybuild/yocto-worker/oe-selftest-armhost/build/build-st-3119200/tmp/work/beaglebone_yocto-poky-linux-gnueabi/u-boot/2025.07/sources/u-boot-2025.07 > > > -T arch/arm/lib/elf_arm_efi.lds -shared -Bsymbolic -s > > > lib/efi_loader/helloworld.o lib/efi_loader/efi_crt0.o > > > lib/efi_loader/efi_reloc.o lib/efi_loader/efi_freestanding.o > > > arch/arm/lib/lib.a -o lib/efi_loader/helloworld_efi.so > > > | arm-poky-linux-gnueabi-ld.bfd: cannot find arch/arm/lib/lib.a: No such > > > file or directory > > > | make[3]: *** [scripts/Makefile.lib:512: > > > lib/efi_loader/helloworld_efi.so] Error 1 > > > > > > The issue is hard to reproduce but this change can artificially trigger > > > it: > > > > > > --- a/scripts/Makefile.build > > > +++ b/scripts/Makefile.build > > > @@ -353,7 +353,7 @@ $(modorder-target): $(subdir-ym) FORCE > > > # > > > ifdef lib-target > > > quiet_cmd_link_l_target = AR $@ > > > -cmd_link_l_target = rm -f $@; $(AR) cDPrsT$(KBUILD_ARFLAGS) $@ $(lib-y) > > > +cmd_link_l_target = rm -f $@ && echo "HACK, delaying build!" && sleep 60 > > > && $(AR) cDPrsT$(KBUILD_ARFLAGS) $@ $(lib-y) > > > > > > $(lib-target): $(lib-y) FORCE > > > $(call if_changed,link_l_target) > > > > > > Then run a rebuild with: > > > > > > $ rm -f $( find build/ -name lib.a -or -name helloworld_efi.so ) && \ > > > make > > > ... > > > arm-poky-linux-gnueabi-ld.bfd -nostdlib -zexecstack -znocombreloc > > > -znorelro --no-warn-rwx-segments -L > > > /home/mcfrisk/src/base/repo/poky/build_bea > > > glebone/tmp/work/beaglebone_yocto-poky-linux-gnueabi/u-boot/2025.07/sources/u-boot-2025.07 > > > -T arch/arm/lib/elf_arm_efi.lds -shared -Bsymbolic -s > > > lib/efi_loader/helloworld.o lib/efi_loader/efi_crt0.o > > > lib/efi_loader/efi_reloc.o lib/efi_loader/efi_freestanding.o > > > arch/arm/lib/lib.a -o lib/efi_loader/helloworld_efi.so > > > arm-poky-linux-gnueabi-ld.bfd: cannot find arch/arm/lib/lib.a: No such > > > file or directory > > > make[3]: *** [scripts/Makefile.lib:512: lib/efi_loader/helloworld_efi.so] > > > Error 1 > > > > > > Fix by introducing PLATFORM_LIBGCC_LIBA variable with only lib.a > > > filename which is then used to add the dependency in rules which use > > > PLATFORM_LIBGCC. This should not impact builds which don't set > > > PLATFORM_LIBGCC_LIBA and PLATFORM_LIBGCC usage stays as is. > > > > > > Fixes: 43d43241d1c9 ("scripts/Makefile.lib: add PLATFORM_LIBGCC to efi > > > linking") > > > > > > Cc: Adriano Cordova <adria...@gmail.com> > > > Cc: Fabio Estevam <feste...@gmail.com> > > > Signed-off-by: Mikko Rapeli <mikko.rap...@linaro.org> > > > > So, this series needs a cover letter. And to reword the commit messages, > > so that the diff to make things fail shows up below the "---". But the > > fatal problem for right now is this needs to be put through CI next > > time. This seems to cause some of the EFI apps to not be built now: > > https://source.denx.de/u-boot/u-boot/-/jobs/1209924 > > > > I assume Azure would have failed too if I let it get that far. Thanks. > > I think I finally figured this out and will send a patch to Makefile in v4. > arch/$(ARCH)/lib and lib are compiled by separate "make" processes started > by top level Makefile, and both use the same scripts/Makefile.build etc. This > threw me off quite a bit. And "make" does not tell which dependencies of a > target are missing if the file level dependency to lib.a is explicit when > linking > the EFI apps. > > I think the single change to build "arch/$(ARCH)/lib" directory before "lib" > in top level Makefile is simple enough to explain in commit message > without a coverletter, similar to how "examples" directory is compiled after > all other directories for u-boot binaries.
Ah, good job figuring this out! -- Tom
signature.asc
Description: PGP signature
