U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Mikko Rapeli <mikko.rapeli@linaro.org>
Cc: u-boot@lists.denx.de, Adriano Cordova <adrianox@gmail.com>,
	Fabio Estevam <festevam@gmail.com>,
	Sughosh Ganu <sughosh.ganu@linaro.org>
Subject: Re: [PATCH v3 1/2] Makefile scripts/Makefile.lib: fix *_efi.so dependency to PLATFORM_LIBGCC
Date: Thu, 31 Jul 2025 10:05:41 -0600	[thread overview]
Message-ID: <20250731160541.GC1807455@bill-the-cat> (raw)
In-Reply-To: <aItY7pLA59ejo1Sa@nuoska>

[-- Attachment #1: Type: text/plain, Size: 5598 bytes --]

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 <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.

Ah, good job figuring this out!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2025-07-31 16:06 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
2025-07-31 16:05     ` Tom Rini [this message]

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=20250731160541.GC1807455@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=adrianox@gmail.com \
    --cc=festevam@gmail.com \
    --cc=mikko.rapeli@linaro.org \
    --cc=sughosh.ganu@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox