From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de, Adriano Cordova <adrianox@gmail.com>,
Fabio Estevam <festevam@gmail.com>
Subject: Re: [PATCH v3 1/2] Makefile scripts/Makefile.lib: fix *_efi.so dependency to PLATFORM_LIBGCC
Date: Thu, 31 Jul 2025 14:52:14 +0300 [thread overview]
Message-ID: <aItY7pLA59ejo1Sa@nuoska> (raw)
In-Reply-To: <20250728214349.GA1750405@bill-the-cat>
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 <adrianox@gmail.com>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@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.
Cheers,
-Mikko
next prev parent reply other threads:[~2025-07-31 11:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-18 8:29 [PATCH v3 1/2] Makefile scripts/Makefile.lib: fix *_efi.so dependency to PLATFORM_LIBGCC Mikko Rapeli
2025-07-18 8:29 ` [PATCH v3 2/2] efi_loader Makefile: change apps from "always" to "targets" Mikko Rapeli
2025-07-23 23:11 ` [PATCH v3 1/2] Makefile scripts/Makefile.lib: fix *_efi.so dependency to PLATFORM_LIBGCC Fabio Estevam
2025-07-28 21:43 ` Tom Rini
2025-07-29 8:19 ` Mikko Rapeli
2025-07-31 11:52 ` Mikko Rapeli [this message]
2025-07-31 16:05 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aItY7pLA59ejo1Sa@nuoska \
--to=mikko.rapeli@linaro.org \
--cc=adrianox@gmail.com \
--cc=festevam@gmail.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.