Re: linux-next: build failure after merge of the arm64 tree

[Stephen Rothwell]

Hi all,

On Wed, 7 Aug 2019 09:33:07 -0700 Peter Collingbourne <pcc@xxxxxxxxxx> wrote:
>
> On Wed, Aug 7, 2019 at 8:25 AM Will Deacon <will@xxxxxxxxxx> wrote:
> >
> > From 71c67a31f09fa8fdd1495dffd96a5f0d4cef2ede Mon Sep 17 00:00:00 2001
> > From: Will Deacon <will@xxxxxxxxxx>
> > Date: Wed, 7 Aug 2019 12:48:33 +0100
> > Subject: [PATCH] init/Kconfig: Fix infinite Kconfig recursion on PPC
> >
> > Commit 5cf896fb6be3 ("arm64: Add support for relocating the kernel with
> > RELR relocations") introduced CONFIG_TOOLS_SUPPORT_RELR, which checks
> > for RELR support in the toolchain as part of the kernel configuration.
> > During this procedure, "$(NM)" is invoked to see if it supports the new
> > relocation format, however PowerPC conditionally overrides this variable
> > in the architecture Makefile in order to pass '--synthetic' when
> > targetting PPC64.
> >
> > This conditional override causes Kconfig to recurse forever, since
> > CONFIG_TOOLS_SUPPORT_RELR cannot be determined without $(NM) being
> > defined, but that in turn depends on CONFIG_PPC64:
> >
> >   $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
> >   scripts/kconfig/conf  --syncconfig Kconfig
> >   scripts/kconfig/conf  --syncconfig Kconfig
> >   scripts/kconfig/conf  --syncconfig Kconfig
> >   [...]
> >
> > In this particular case, it looks like PowerPC may be able to pass
> > '--synthetic' unconditionally to nm or even drop it altogether. While
> > that is being resolved, let's just bodge the RELR check by picking up
> > $(NM) directly from the environment in whatever state it happens to be
> > in.
> >
> > Cc: Peter Collingbourne <pcc@xxxxxxxxxx>
> > Reported-by: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> > Suggested-by: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
> > Signed-off-by: Will Deacon <will@xxxxxxxxxx>  
> 
> Tested-by: Peter Collingbourne <pcc@xxxxxxxxxx>
> Reviewed-by: Peter Collingbourne <pcc@xxxxxxxxxx>

Thanks for sorting this out (even temporarily).

-- 
Cheers,
Stephen Rothwell

Attachment: pgpn96KgXMkQ_.pgp
Description: OpenPGP digital signature