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: Tue, 29 Jul 2025 11:19:29 +0300 [thread overview]
Message-ID: <aIiEEUsOmqOMLS_d@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
Ok, I can add a cover letter but details need to be in commit message too.
I'm surprised how many things have failed when commit message has a diff
but I will describe the test in some way there.
The issues seen in yocto autobuilder are fixed by the first patch.
Second patch is for the failure I saw when building with the hack
which delays linking. This breaks the EFI app builds and I can
reproduce that. The patch is somehow wrong, but without it the artificially
delayed linking step fails in my test builds. I'll investigate this more.
Cheers,
-Mikko
next prev parent reply other threads:[~2025-07-29 8:19 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 [this message]
2025-07-31 11:52 ` Mikko Rapeli
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=aIiEEUsOmqOMLS_d@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.