From: Peter Korsgaard <peter@korsgaard.com>
To: Julien Olivain <ju.o@free.fr>
Cc: "Yann E . MORIN" <yann.morin.1998@free.fr>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH RFC 1/1] boot/edk2: unset MAKEFLAGS in build environment
Date: Wed, 10 Jan 2024 21:09:02 +0100 [thread overview]
Message-ID: <87bk9t9cip.fsf@48ers.dk> (raw)
In-Reply-To: <20231231181437.582286-1-ju.o@free.fr> (Julien Olivain's message of "Sun, 31 Dec 2023 19:14:37 +0100")
>>>>> "Julien" == Julien Olivain <ju.o@free.fr> writes:
> Yann reported in [1] that edk2 build could sometimes fail. The issue
> can be reproduced when per-package directories is enabled, or also
> when building on a system with GNU Make >= 4.4 using the
> "--shuffle=reverse" option (such as Fedora 39). Those are pointing
> toward a Makefile dependency issue.
> The issue can be reproduced with commands:
> cat > .config <<EOF
> BR2_riscv=y
> BR2_RISCV_64=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TARGET_EDK2=y
> EOF
> make olddefconfig
> Then, building either with:
> make --shuffle=reverse
> Or:
> utils/config -e BR2_PER_PACKAGE_DIRECTORIES
> make olddefconfig
> make -j$(nproc)
> It is interesting to mention that when using "make --shuffle=reverse"
> to build, the build can be completed if restarted only with "make". It
> will not pull any other Buildroot package. This fact hints toward a
> Makefile dependency issue internal to the EDK2 build system, rather
> than in the Buildroot recipe.
> The EDK2 build system is quite unique. See [2]. It generates files,
> makefiles and internally uses GNU Make to compile code. This system is
> likely not tested as being a sub-Make process in a complex Makefile
> such as Buildroot.
> In order to prevent Buildroot to pass unexpected Make flags to the
> EDK2 sub-Make, this commit unset the MAKEFLAGS variable in the EDK2
> build environment. This will put the EDK2 build script in a more
> common and tested state. See GNU Make documentation about recursive use
> of Make, more specifically [3].
> Note: as mentioned, the build failure is likely due to an internal
> issue of the EDK2 build system. The failure points to a missing
> dependency in the EDK2 generator itself. This commit does not fix this
> issue, but rather put the EDK2 build system in a normalized
> environment, avoiding Buildroot flags being passed to the internal
> EDK2 sub-Make invocation. The upstream EDK2 build system most likely
> need a fix too.
> Fixes:
> make[2]: *** No rule to make target '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp/DEBUG/UiApp.efi', needed by '/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/FV/Ffs/462CAA21-7614-4503-836E-8AB6F4662331UiApp/UiApp.offset'. Stop.
> build.py...
> : error 7000: Failed to execute command
> make tbuild [/buildroot/output/build/edk2-edk2-stable202308/Build/RiscVVirtQemu/RELEASE_GCC5/RISCV64/MdeModulePkg/Application/UiApp/UiApp]
> build.py...
> : error F002: Failed to build module
> /buildroot/output/build/edk2-edk2-stable202308/MdeModulePkg/Application/UiApp/UiApp.inf [RISCV64, GCC5, RELEASE]
> [1] https://lists.buildroot.org/pipermail/buildroot/2023-December/681507.html
> [2] https://tianocore-docs.github.io/edk2-BuildSpecification/draft/4_edk_ii_build_process_overview/42_build_process_overview.html
> [3] https://www.gnu.org/software/make/manual/make.html#Options_002fRecursion
> Reported-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Signed-off-by: Julien Olivain <ju.o@free.fr>
Nice description!
Committed to 2023.02.x and 2023.11.x, thanks.
--
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
prev parent reply other threads:[~2024-01-10 20:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 18:14 [Buildroot] [PATCH RFC 1/1] boot/edk2: unset MAKEFLAGS in build environment Julien Olivain
2024-01-01 21:27 ` Yann E. MORIN
2024-01-10 20:09 ` Peter Korsgaard [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=87bk9t9cip.fsf@48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@buildroot.org \
--cc=ju.o@free.fr \
--cc=yann.morin.1998@free.fr \
/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.